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 15:14:41 GMT
On 11 September 2011 15:39, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 9/11/11 6:53 AM, sebb wrote:
>> 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.
>
> 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?

Yes.

No need for the tag name, can check out as follows:

Normal checkout:

svn co http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC6
svn info MATH_2_2_RC6
URL: http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC6
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1169466
Node Kind: directory
Schedule: normal
Last Changed Author: luc
Last Changed Rev: 1074893
Last Changed Date: 2011-02-26 18:12:22 +0000 (Sat, 26 Feb 2011)

Without using RC tag (we do need a tag or we get all the tags)

svn co http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2
-r 1074893 MATH_2_2_1074893
svn info MATH_2_2_1074893
URL: http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC6
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1074893
Node Kind: directory
Schedule: normal
Last Changed Author: luc
Last Changed Rev: 1074893
Last Changed Date: 2011-02-26 18:12:22 +0000 (Sat, 26 Feb 2011)


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

Of course. The entry in the manifest is mainly for our use; it's not
intended to replace the documentation.


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