+1 for generating changelog.html
On Sun, Feb 17, 2013 at 3:23 AM, Christoph Kutzinski <[email protected]> wrote: > Would be a nice addition. > Another nuisance are the frequent merge conflicts on changelog.html > > 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. > > Am 15.02.2013 13:56, schrieb cjo: > > Keeping on the theme of improving the release process and correctly > tagging of issues to releases. > > Seeing as Jesse keeps commenting on pull requests to add @since to new > classes/Methods. > Can there be a definition that developers can use that would be replaced > when the release is made, > so that the information is correct and developers do not need to guess > when their changes are going to be added/released into the core > > I suggest that we have something like > JenkinsReleaseVersion > > and we could reference it like > /** > * @since {JenkinsReleaseVersion} > */ > public String someMethod() {} > .. > > and at release time these would be replaced with the correct version > like 1.502 > > Chris > > On Wednesday, 13 February 2013 23:14:04 UTC, Jesse Glick wrote: >> >> We have some bot which comments in JIRA when a commit relating to an >> issue appears in the trunk continuous build. This is fine and well, but I >> have for one have never >> wanted to know this. >> >> What _is_ important is when the fix lands in an official (weekly) >> release. Users frequently ask this [1] but it is awkward to find the >> answer. The changelog [2] should >> say, if the committer remembered to update the changelog, and you know to >> click the “Upcoming changes” link. >> >> If you have a source checkout you can use >> >> ---%<--- ~/.gitconfig >> [alias] >> which = describe --contains >> ---%<--- >> >> to get a clue where a change appeared, though only after the release tag >> is made. And even for those who have the source checkout, this is an >> annoying context switch when >> you are reviewing historical issues. >> >> Much nicer would be if some bot would add a simple comment to JIRA after >> the release is published: >> >> This fix is in Jenkins 1.502. >> >> and link to the changelog. This would be clearly visible in the issue >> history, and send notifications to watchers. Anyone capable of making that >> happen? >> >> >> [1] https://issues.jenkins-ci.org/**browse/JENKINS-15156?** >> focusedCommentId=173823&page=**com.atlassian.jira.plugin.** >> system.issuetabpanels:comment-**tabpanel#comment-173823<https://issues.jenkins-ci.org/browse/JENKINS-15156?focusedCommentId=173823&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-173823> >> [2] http://jenkins-ci.org/**changelog <http://jenkins-ci.org/changelog> >> > -- > 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. > > > -- Website: http://earl-of-code.com -- 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.
