commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [parent] adding buildnumber in the manifest entries
Date Sat, 10 Sep 2011 16:04:46 GMT
On 10 September 2011 16:28, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 9/10/11 8:18 AM, sebb wrote:
>> On 10 September 2011 16:09, Phil Steitz <phil.steitz@gmail.com> wrote:
>>> Could be I am misunderstanding the proposal here, but IIUC there is another problem
when it comes to release jars.  Current practice is to create the jars from what ends up
being the final RC tag.  This tag is then either copied or moved to the release tag, which
becomes the definitive source.  So at the time the jar is created, the tag/revision pair
that the build number should point to does not exist.  The only choice would seem then to
be to reference the RC tag which may end up deleted.  So again, it would seem better to me
to either omit the attribute from release jars or just use the (anticipated) final release
tag name.
>> Tag rename/copy history unfortunately shows the repo revision at the
>> time of the copy which makes it quite hard to know what revision was
>> actually used for the build. You have to scan the history to check for
>> changes.
>>
>> The point is just to record what was used to create the jars.
>> Yes, this will differ from the final tag, but having the information
>> is better than not having it, IMO.
>
> Not sure I agree.  Seems to me the whole point of having a release
> tag - the final one that should really be immutable, is that it
> points unambiguously to the source used to build the distribution.

Agreed.

> Why do we need to complicate things by referencing revision numbers
> of (possibly deleted) RC tags?

Because the official release tag was not used to build the project.

The only way to know what was actually used is to record the tag and
revision number.

We don't have to store it in the jar manifests, but that seems as good
a place as any.

>>
>> Note:
>> One solution to all this uncertainty is to abandon RCs, and just use
>> revision numbers.
>> If the vote fails, bump the revision number and throw away the old
>> revision and tag. This is what Tomcat and Httpd do.
>
> Can you explain exactly how that works?

This is the process AIUI:

Tag 7.0.22 from trunk; build, vote.

Vote succeeds - release 7.0.22.

Vote fails, create tag 7.0.23 from updated trunk, build and redo vote
Tag 7.0.22 could now be deleted, but I think they keep all the tags.

Their achives [1] for 7.0.x don't contain 13, 17, 18; but the tags [2] do.

[1] http://archive.apache.org/dist/tomcat/tomcat-7/
[2] http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/
> Phil
>>
>>> Phil
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message