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