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