-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Create a system to enforce that PR authors are responsible for updating the changelog #5670
Comments
Do you mean that each PR would include an entry in the CHANGELOG under a I'm 👍 for this. I've always preferred to update the CHANGELOG as part of each PR, but for my PR's I haven't simply because it wasn't being done that way. Added bonus is people can see what changes are coming soon in the next release. |
Downside of this is it triggers a merge conflict in almost every PR. |
there are a fair number of PRs that would not warrant an update in the changelog (changes to testing patterns or internal refactors that don't affect end users). I'd prefer a checkbox on the PR template to a hard requirement 🤷♀️ |
The underlying problem here is that manually building the changelog from the git history each time we do a release can be quite difficult and time consuming. An alternative solution to requiring a changelog update in each PR might be to use some sort of system for commit comments, a la https://commitizen.github.io/cz-cli/, to make it easier to build the changelog. |
I'm loving all these ideas! Just edited the issue title to increase the design space a little. |
Good release notes require some manual curation, whether it’s at release time or periodically during the release cycle. Here are some examples I’ve seen from gardening the iOS SDK’s release notes:
Commitzen can certainly make it easier to perform that curation, but the biggest improvement would come from treating CHANGELOG.md as a draft release notes and curating it multiple times during a release cycle, while the context is still fresh. |
As for a system of enforcement, I’d recommend Danger, which works by commenting on the PR instead of updating webhooks. Danger can leave a reminder as a warning without failing the build. |
Considering the merge conflict issue @jfirebaugh mentions above, and @1ec5 's point about manual curation, I propose that we attempt to streamline--but not fully automate--this process by doing the following:
1 is more important than 2, but I think 2 is a good idea because it essentially asks the the author of a change to handle thinking about how best to communicate it, thus avoiding the situation where the person running the release doesn't have enough context to do so and has to chase down the author to figure out what to say. |
Edit: I just realized this ticket is in the gl-js repository rather than the gl-native repository. Never mind me. 😅
|
@1ec5 my intent in #5670 (comment) was that we'd continue to track CHANGELOG.md in source control and update it at the time of each release (usually in the
Why weekly, rather than just with each release?
👍 to categorization and sorting by impact. Good point about cutting down merge conflicts -- but there's still likely to be conflict on the 2nd and 3rd change in each category, right? |
I posted #5670 (comment) before realizing this isn’t the gl-native repository, where we already maintain a running changelog on each merge but sometimes miss stuff that happens in mbgl. Sorry for the confusion. |
Quick first cut at this changelog-draft script here: https://github.com/mapbox/github-release-tools Here's an example of what it currently generates: https://gist.github.com/anandthakker/a913b632c719f57a4bf6e8356943f868 |
Looks good. I noticed that the hat tipping logic is based on the PR coming from a fork, I'm not sure how many external contributors you have with commit access, but right now it won't automatically hat tip their PRs. It's not an issue for my contributions, but something to keep in mind for others... |
#9023 proposes an option to tag the changeset category with a github label and use the PR title or |
I'll close this issue since #9023 is in place allowing PR authors to set the changelog entry and label for category (which I believe then get's auto populated into the changelog at release time). If this still doesn't address the request, feel free to re-open. |
The pace of development and complexity of GL JS makes it time consuming and error prone for the engineer doing the release to write the whole change log by hand at release time.
We could consider following the lead of other teams at Mapbox and require that PR authors update the change log if their changes affect end users or explicitly opt out from updating the change log if the changes do not affect end users.
The text was updated successfully, but these errors were encountered: