Aw: Re: Which build has that fix?

2013-02-19 Thread Christoph Kutzinski
@googlegroups.com 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

Re: Which build has that fix?

2013-02-19 Thread Stephen Connolly
Jesse, I think I have you spoiled with the 'Bees release notes app... even with the complaints you file in redmine! On 18 February 2013 19:20, Jesse Glick jgl...@cloudbees.com wrote: On 02/17/2013 05:23 AM, Christoph Kutzinski wrote: Another nuisance are the frequent merge conflicts on

Re: Aw: Re: Which build has that fix?

2013-02-19 Thread Jesse Glick
On 02/19/2013 07:34 AM, Christoph Kutzinski wrote: 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? There might need to be a way to

Re: Which build has that fix?

2013-02-18 Thread Jesse Glick
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

Re: Which build has that fix?

2013-02-18 Thread Michael Clarke
Going back to Jesse's original email: I've committed my Issue Update Bot code to Github [1], although am waiting for my pull request on Github-API [2] to be accepted before anyone else could build this (unless they build a snapshot version of my changes [3]). The jenkins-issues bot is currently

Re: Which build has that fix?

2013-02-17 Thread Christoph Kutzinski
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

Re: Which build has that fix?

2013-02-17 Thread Slide
+1 for generating changelog.html On Sun, Feb 17, 2013 at 3:23 AM, Christoph Kutzinski ku...@gmx.de 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

Re: Which build has that fix?

2013-02-15 Thread 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

Re: Which build has that fix?

2013-02-15 Thread Stephen Connolly
could be dangerous... what happens when the commit gets cherry-picked back... you'd then have @since 1.480.4 and @since 1.502 and the reality is you can only rely on it with 1.502+ On 15 February 2013 12:56, cjo cjo.john...@gmail.com wrote: Keeping on the theme of improving the release process

Re: Which build has that fix?

2013-02-15 Thread Michael Clarke
I've pulled together some code that does roughly what I think Jesse is looking for by: 1. Listening on #jenkins-commits channel on IRC 2. Watching for a message with 'prepare release' in it (the standard Maven release string), pulling the version number and commit ID from that 3. Call the GitHub

Which build has that fix?

2013-02-13 Thread Jesse Glick
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]