On 10 September 2011 15:46, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 9/9/11 2:34 PM, sebb wrote:
>> On 9 September 2011 19:58, Phil Steitz <phil.ste...@gmail.com> 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.
Tags are often deleted and recreated, though I think generally only
before being proposed for a vote.
I would hope that a tag which is ever used in a vote is never
recreated for a new vote.
So in that sense they are immutable.
And I would hope that tags that have been released are not subsequently amended.
Though potentially they might be deleted, if the RC tag is renamed
rather than copied for the release tag
>>
>> 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.
Yes, we need both.
>>
>> 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
> standardized?
No idea about standards.
I've added the tag name.
The value is now
${scmBranch}@r${buildNumber}; ${maven.build.timestamp}
which will show both, assuming that the build is done from a clean
checkout of the SVN tag.
The point of adding the entry is to automatically document what was
used to do the build.
> Phil
>>
>>> 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
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
