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 Sun, 11 Sep 2011 14:41:58 GMT
On 9/11/11 7:39 AM, Phil Steitz wrote:
> On 9/11/11 6:53 AM, sebb wrote:
>> On 11 September 2011 14:43, Phil Steitz <> wrote:
>>> On 9/11/11 3:26 AM, Luc Maisonobe wrote:
>>>> Le 11/09/2011 02:51, sebb a écrit :
>>>>> On 10 September 2011 21:12, Phil Steitz<>
>>>>> wrote:
>>>>>> On 9/10/11 10:34 AM, sebb wrote:
>>>>>>> On 10 September 2011 17:58, Phil Steitz<>
>>>>>>> wrote:
>>>>>>>> On 9/10/11 9:21 AM, Ralph Goers wrote:
>>>>>>>>> Are you guys arguing about manifests or build processes.
>>>>>>>>> can't really tell.
>>>>>>>>> There is no perfect build process. I'm not a fan of voting
>>>>>>>>> an RC and then renaming the tag and so with VFS I created
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> impact on the build process.  I think it is best to avoid
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> release
>>>>>>>> jar it is not sufficient to identify the source.  I think
>>>>>>>> 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.
>>>> Yes, but we also have many eyes looking at svn changes, we have
>>>> processed and we have people who can rollback unwanted changes.
>>>> I guess our users expect us to do our best to avoid this and to
>>>> have reproducible and understandable builds. If it is only a
>>>> process that say a tag once voted on should not change and this
>>>> process is backed up by the foundation as a whole, it is already
>>>> something good.
>>>> So my point is that both revision numbers or tags could be stored
>>>> in the manifest. Tags are easier to understand to users. Revision
>>>> numbers are easier for the automated build process. I'm still not
>>>> sure which one is better.
>>> Revision numbers in the manifest only make sense for snapshots or
>>> forks, IMO. This is because as pointed out several times on this
>>> thread already, in order for them to make sense for release jars,
>>> they have to be precised by adding the RC tag name, which may well
>>> not exist post release.
>> Which does not matter, as the source can still be retrieved using the revision.
> How exactly?  I am asking this because I don't know how to do it. 
> Won't whoever wants to retrieve it have to know the (now
> non-existent) tag name?  Or will it work from a checkout/URL of
> trunk or the actual release tag?

Sorry, brain dead there.  Forgot you were planing to put the RC tag
name in the entry.  Might seem a little odd to try to check out a
tag that is no longer there, but I guess it would work.
> In any case, I  really think we should be conditioning users to use
> the release tag to get the definitive release sources.
> Phil
>>> Phil
>>>> Luc
>>> ---------------------------------------------------------------------
>>> 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