commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [parent] adding buildnumber in the manifest entries
Date Sat, 10 Sep 2011 14:46:42 GMT
On 9/9/11 2:34 PM, sebb wrote:
> On 9 September 2011 19:58, Phil Steitz <> wrote:
>> On 9/9/11 12:35 AM, Simone Tripodi wrote:
>>> Good morning guys,
>>> I just did an experiment on my local checkout of the parent pom,
>>> adding the buildnumber plugin, in order to have a new
>>> `Implementation-Build` manifest entry in the jars, where reported the
>>> revision number and the timestamp.
>>> I applied locally on [chain] and got:
>>>     Implementation-Build: r1166864; 2011-09-09 09:17:22+0200
>> Is there any way to either suppress the entry or get a tag name put
>> in place of the revision number when we cut releases?  I guess what
>> you end up with is the revision number of the winning RC tag in
>> release jars.  Are we sure we want to do that?
> Yes, I think the revision number is very useful.
> More so than the tag name, because revision numbers are immutable.

Tags should be immutable.  If our release tags are not, we have a
big problem.
> The revision number documents what was actually used to build the code
> (assuming a clean workspace).

Should in all cases be identical to the release tag.   What I am
worried about is the ambiguity.  I could be wrong on this, but
assuming I want to recover exactly what was used to build the
release I know I can do that by checking out the release tag or
building from the source distribution.  That is the invariant that
users should expect us to maintain.  How exactly will this work with
the revision number in the manifest?  I can imagine some users
thinking this corresponds to trunk, which will be incorrect.  To
actually get the right source, they will have to know the name of
the tag, which is enough to get the source by itself, making the
revision number redundant and possibly misleading.
> The buildScmBranch property can be used to document the branch/tag
> name (trunk => trunk, which is not all that useful!)

I guess what you are saying here is we need to add the tag name
elsewhere?  Is that a standard manifest entry?  Is any of this

>> Phil
>>> I'd like to commit it if no one has objections, if needed I can fill
>>> an Issue and attach the patch.
>>> Please let me know, thanks in advance!
>>> Have a nice day,
>>> Simo
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message