That's a nice idea. But I wonder about 2 points:
- what if you forgot to put ‘[FIXED JENKINS-12345]’ into the commit message. If it haven't been released, yet, it's certainly easy to add a 'bogus' commit with that message, but what if it was already released?
- what if you want to add more info in the changelog (announcement of new features, warnings about backward-incomaptible changes, migration steps)? That is IMO not something which belongs into a commit message.
Gesendet: Montag, 18. Februar 2013 um 20:20 Uhr
Von: "Jesse Glick" <[email protected]>
An: [email protected]
Betreff: Re: Which build has that fix?
Von: "Jesse Glick" <[email protected]>
An: [email protected]
Betreff: Re: Which build has that fix?
On 02/17/2013 05:23 AM, Christoph Kutzinski wrote:
> Another nuisance are the frequent merge conflicts on changelog.html
Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too.
> A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html.
Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked
out—the only real truth, after all. Commit messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ or ‘Merged pull request #1001’ would produce
sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose.
[1] https://github.com/cloudbees/autochangelog-maven-plugin
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
> Another nuisance are the frequent merge conflicts on changelog.html
Yes, this complicates pull requests, and makes backporting fixes to the stable branch painful too.
> A rough idea would be to create a new single file (XML or so) for each changelog entry and let the release process merge this into a single changelog.html.
Better to not store changelog.html in Git at all. Just provide a tool to generate target/changelog.html from the Git changelog leading up to the revision you have checked
out—the only real truth, after all. Commit messages including keys such as ‘[FIXED JENKINS-12345]’ or ‘[SECURITY-99]’ or ‘Merged pull request #1001’ would produce
sensible hyperlinks. autochangelog-maven-plugin [1] could probably be adapted to this purpose.
[1] https://github.com/cloudbees/autochangelog-maven-plugin
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
