@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
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
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
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
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
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
+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
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
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
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
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]
11 matches
Mail list logo