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 Sun, 11 Sep 2011 13:53:32 GMT
On 11 September 2011 14:43, Phil Steitz <phil.steitz@gmail.com> 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<phil.steitz@gmail.com>
>>> wrote:
>>>> On 9/10/11 10:34 AM, sebb wrote:
>>>>> On 10 September 2011 17:58, Phil Steitz<phil.steitz@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.
>>
>> 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.

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