On 10 September 2011 21:12, Phil Steitz <phil.ste...@gmail.com> wrote:
> 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'm not saying it has happened, but it could.
There's nothing to stop updates to tags; they can happen accidentally
or maliciously.

>>
>> 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.

AFAIK, you can still extract the code from SVN, even if the tag has
been deleted.

Without the revision, it's impossible to be certain that you have the
correct code.

> 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
>
>

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

Reply via email to