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