micrometer icon indicating copy to clipboard operation
micrometer copied to clipboard

Published 20 hours ago • verified publisher icon micrometer-metrics

Automate generating changelog as part of release

Open coditori opened this issue 4 years ago • 7 comments

Hi Guys, Thanks for your incredible work, it's really hard to find out what are the changes in the new release, if you can provide CHANGELOG.md it would be really helpful and appreciated.

Thanks

coditori avatar Dec 13 '20 12:12 coditori

@coditori You mean something like this? https://github.com/micrometer-metrics/micrometer/releases

jonatan-ivanov avatar Dec 14 '20 00:12 jonatan-ivanov

We use GitHub's milestones to link issues with a release version, and we link to that milestone in the GitHub release. For minor version releases, the release includes a summary of changes. For patch releases, we defer to the milestone except for any breaking type of changes/regressions which are called out in the release notes.

Were you aware of the releases and milestones? If so, what benefit would a changelog add? My initial thoughts are that it feels like duplicated work that requires commits to the repository to update, and it would lack the context that is in the linked issues/pull requests of a milestone.

shakuzen avatar Dec 14 '20 03:12 shakuzen

Hi guys, this general text "This patch release contains changes from ..." means nothing for us :) Then we should go and check many issues which are linked to each other with different tags (duplicate, ...) to find out which issue is related to this release.

Please just check this structure it's really helpful: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md

coditori avatar Dec 15 '20 08:12 coditori

We can explore automating copying issue titles into the release text of GitHub releases, which seems it would solve your dissatisfaction with the current release text provided. I'm still not in favor of a standalone changelog file in source control.

shakuzen avatar Dec 16 '20 03:12 shakuzen

I think we can look at incorporating this github-changelog-generator as part of our release process. We incidentally may want to review and document our issue handling rules for consistent results.

shakuzen avatar Jan 13 '21 09:01 shakuzen

I think we can look at incorporating this github-changelog-generator as part of our release process.

I have tried this tool out manually for the 1.3.17 release. I'm pretty happy with the results. Let me know what you think. For the next patch releases containing changes merged forward from this one, we'll need to figure out how to include those in the changelog, since we don't currently create forward-port issues for this.

Organization of the changes is something else to consider. It would be good to clearly indicate/organize changes for a specific MeterRegistry implementation, but I'm not sure on the best method yet. We'll experiment with this as we work to automate this as part of our release process.

shakuzen avatar Feb 17 '21 09:02 shakuzen

Reopening and repurposing the issue to be about automating and integrating usage of the github-changelog-generator into our release process, since it currently involves some manual work.

shakuzen avatar Mar 01 '21 11:03 shakuzen

How about we add this action so that this happens automatically (check the generate release notes option)?

If we don't want to use that option, we can modify our scripts to use https://github.com/spring-io/github-changelog-generator and then use the created file as body parameter of the create release action.

Please provide your opinion and I can configure the rest

marcingrzejszczak avatar Dec 22 '23 11:12 marcingrzejszczak