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. Phil > > Luc > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
