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 a
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 wrote:
> On 02/17/2013 05:23 AM, Christoph Kutzinski wrote:
>
>> Another nuisance are the frequent merge conflicts on changelog.html
>>
>
>
ck"
An: jenkinsci-dev@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
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 l
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
ch
+1 for generating changelog.html
On Sun, Feb 17, 2013 at 3:23 AM, Christoph Kutzinski 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 th
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 o
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 AP
On 02/15/2013 08:15 AM, Stephen Connolly wrote:
@since 1.480.4 and @since 1.502 and the reality is you can only rely on it with
1.502+
True, although most users going forward would either be using 1.480.{4+} or
1.{502+}, not 1.481–1.501.
A related risk: if you use the 1.480.3 plugin parent P
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 wrote:
> Keeping on the theme of improving the release process and correctly
> tagg
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 t
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
12 matches
Mail list logo