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