Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Finetune automatic changelogs #840

Merged
merged 8 commits into from
Dec 1, 2023
Merged
Show file tree
Hide file tree
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
Expand Up @@ -7,9 +7,16 @@ updates:
directory: "/"
schedule:
interval: "weekly"
commit-message:
prefix: chore
include: scope
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "daily"
versioning-strategy: "increase-if-necessary"
open-pull-requests-limit: 20
commit-message:
prefix: fix
prefix-development: chore
include: scope
5 changes: 5 additions & 0 deletions .github/workflows/pr-title-validation.yml
Original file line number Diff line number Diff line change
Expand Up @@ -20,3 +20,8 @@ jobs:
- uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
types: |
fix
feat
chore
7 changes: 6 additions & 1 deletion documentation/publishing.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,12 @@ If you want to have rights to publish as well, contact one of the [maintainers](
## Conventional commits

In order to know whether a release is major, minor or patch and to automatically generate changelogs, we use the [conventional commits spec](https://www.conventionalcommits.org/en/v1.0.0/).
In our PR titles, we specify whether a change is a patch, a fix (minor) or a breaking change (major).
In our PR titles, we specify whether a change is a fix (patch), a new feature (minor) or a breaking change (major).
If you want to make a change without triggering a new release, use the `chore` prefix.

Note: Only use this prefix when updating development dependencies, changing configuration or updating documentation which isn't about a component.
For refactors, regular dependency updates or updates to documentation about components, use the `fix` prefix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest using a list and moving the empty line to make this easier to scan:

Suggested change
In our PR titles, we specify whether a change is a fix (patch), a new feature (minor) or a breaking change (major).
If you want to make a change without triggering a new release, use the `chore` prefix.
Note: Only use this prefix when updating development dependencies, changing configuration or updating documentation which isn't about a component.
For refactors, regular dependency updates or updates to documentation about components, use the `fix` prefix.
The titles of our PR’s specify whether a change is:
* a `chore`, which doesn’t trigger a release
* a `fix`, resulting in a patch release,
* a new feature (`feat`), a minor release, or
* a breaking change (`feat!`), a major release.
Use the `chore` prefix when updating development dependencies, changing configuration or updating documentation which isn't about a component.
For refactors, regular dependency updates or updates to documentation about components, use the `fix` prefix.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reading the last two sentences makes me wonder whether we should introduce two different prefixes for dependencies (or something more general to include e.g. CI) and documentation after all.

Documentation is an essential part of a library; we shouldn’t swipe new non-component docs under the rug.

And an actual bug fix is something different than a dependency update. Consumers will be very interested in the former, not so much in the latter.

Copy link
Contributor Author

@alimpens alimpens Nov 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation is an essential part of a library; we shouldn’t swipe new non-component docs under the rug.

Hm, do you think a change to say coding-conventions.md is relevant for the consumers of our packages? Same goes for dev dependencies, if it doesn't change the code or docs we ship, it's irrelevant, no?

And an actual bug fix is something different than a dependency update. Consumers will be very interested in the former, not so much in the latter.

True, but semver doesn't really offer room for that distinction I think. Any change to the code we ship which doesn't add a feature or breaks backwards compatibility is considered a patch release.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, do you think a change to say coding-conventions.md is relevant for the consumers of our packages? Same goes for dev dependencies, if it doesn't change the code or docs we ship, it's irrelevant, no?

Oh no, not the ‘internal’ docs. I was thinking of pages like our design guidelines on grid, typography etc.

True, but semver doesn't really offer room for that distinction I think. Any change to the code we ship which doesn't add a feature or breaks backwards compatibility is considered a patch release.

Certainly. I was envisioning the change log, where I think separate headings or lists for documentation and dependencies might be in order. How about that?

Copy link
Contributor Author

@alimpens alimpens Nov 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh no, not the ‘internal’ docs. I was thinking of pages like our design guidelines on grid, typography etc.

Those aren't part of packages we publish, so changes to them won't trigger a release anyway. Only changes to files in packages/* and proprietary/* trigger a release.

Certainly. I was envisioning the change log, where I think separate headings or lists for documentation and dependencies might be in order. How about that?

Yeah, definitely, we could use scopes for that. We would need to decide on a list of scopes to make them meaningful, I think. The proposed change in this PR already takes care of a part of that, Dependabot PRs should get a scope of deps

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those aren't part of packages we publish

Oh yeah, of course.

we could use scopes for that

Great.

The PR title also describes the change in a clear, human-friendly way.
This PR title becomes the description of a commit when we squash merge a feature branch PR into `develop`.
These commit descriptions are eventually used to figure out the release type and to generate entries into our changelogs.
Expand Down
1 change: 1 addition & 0 deletions lerna.json
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@
"conventionalCommits": true,
"exact": true,
"private": false,
"skipBumpOnlyReleases": true,
"syncWorkspaceLock": true
}
}
Expand Down