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:39:36 GMT
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
>>>>>>>> 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
>>>>>>> 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
>>>>>>> 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.
>>> 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?

In any case, I  really think we should be conditioning users to use
the release tag to get the definitive release sources.

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