On 9/10/11 10:34 AM, sebb wrote:
> On 10 September 2011 17:58, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On 9/10/11 9:21 AM, Ralph Goers wrote:
>>> Are you guys arguing about manifests or build processes. I can't really 
>>> tell.
>>>
>>> There is no perfect build process. I'm not a fan of voting on an RC and 
>>> then renaming the tag and so with VFS I created the tag over and over again 
>>> for each candidate. That has its own pitfalls but works since Nexus 
>>> supports it well.  If we were following the Tomcat and Httpd model I think 
>>> the first release of VFS 2.0 would have been 2.0.20.  I would think that 
>>> would make it hard for users to understand what the latest version is, but 
>>> if it works for them I'd be interested to know more. Maybe their releases 
>>> never fail.
>> I agree with you on this, Ralph.  I am not sure it is best for us to
>> go down the tc/httpd path as it may be confusing to users.  What we
> IMO it's only confusing if there really are a lot of "missing" releases.
> I think Tomcat may do additional checks on the code before putting the
> tag up for formal release vote.
> This can be done on snapshots or even RCs.
>
>> are talking about here is what to put in the manifest of release
>> jars.  If we want to put revision numbers in there (I am personally
>> not sold on this), the meaningfulness of what we put in will have
>> impact on the build process.  I think it is best to avoid this can
>> of worms and just either leave the attribute off of release jars (as
>> it is only really needed for snaps) or put the final release tag
>> name there.  I don't buy the argument that because the release tag
>> is a copied or moved version of the source used to build the release
>> jar it is not sufficient to identify the source.  I think it should
>> *definitively* identify the source.
> It should, but it doesn't necessarily.

Where exactly?  Do we have release tags that do not correspond
exactly with the release sources now?  If so, that is a problem that
needs to be fixed.
>
> I don't see what the harm is in adding the header line.

If it refers to a revision of a deleted tag, I don't see the point
in it.

Phil
>
>> Phil
>>> Ralph
>>>
>>> On Sep 10, 2011, at 9:04 AM, sebb wrote:
>>>
>>>> On 10 September 2011 16:28, Phil Steitz <phil.ste...@gmail.com> wrote:
>>>>> On 9/10/11 8:18 AM, sebb wrote:
>>>>>> On 10 September 2011 16:09, Phil Steitz <phil.ste...@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-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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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

Reply via email to