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. >> >> I don't see what the harm is in adding the header line. > > If it refers to a revision of a deleted tag, I don't see the point > in it. AFAIK, you can still extract the code from SVN, even if the tag has been deleted. Without the revision, it's impossible to be certain that you have the correct code. > Phil >> >>> Phil >>>> Ralph >>>> >>>> On Sep 10, 2011, at 9:04 AM, sebb wrote: >>>> >>>>> On 10 September 2011 16:28, Phil Steitz <phil.ste...@gmail.com> wrote: >>>>>> On 9/10/11 8:18 AM, sebb wrote: >>>>>>> On 10 September 2011 16:09, Phil Steitz <phil.ste...@gmail.com> wrote: >>>>>>>> Could be I am misunderstanding the proposal here, but IIUC there is >>>>>>>> another problem when it comes to release jars. Current practice is to >>>>>>>> create the jars from what ends up being the final RC tag. This tag is >>>>>>>> then either copied or moved to the release tag, which becomes the >>>>>>>> definitive source. So at the time the jar is created, the >>>>>>>> tag/revision pair that the build number should point to does not >>>>>>>> exist. The only choice would seem then to be to reference the RC tag >>>>>>>> which may end up deleted. So again, it would seem better to me to >>>>>>>> either omit the attribute from release jars or just use the >>>>>>>> (anticipated) final release tag name. >>>>>>> Tag rename/copy history unfortunately shows the repo revision at the >>>>>>> time of the copy which makes it quite hard to know what revision was >>>>>>> actually used for the build. You have to scan the history to check for >>>>>>> changes. >>>>>>> >>>>>>> The point is just to record what was used to create the jars. >>>>>>> Yes, this will differ from the final tag, but having the information >>>>>>> is better than not having it, IMO. >>>>>> Not sure I agree. Seems to me the whole point of having a release >>>>>> tag - the final one that should really be immutable, is that it >>>>>> points unambiguously to the source used to build the distribution. >>>>> Agreed. >>>>> >>>>>> Why do we need to complicate things by referencing revision numbers >>>>>> of (possibly deleted) RC tags? >>>>> Because the official release tag was not used to build the project. >>>>> >>>>> The only way to know what was actually used is to record the tag and >>>>> revision number. >>>>> >>>>> We don't have to store it in the jar manifests, but that seems as good >>>>> a place as any. >>>>> >>>>>>> Note: >>>>>>> One solution to all this uncertainty is to abandon RCs, and just use >>>>>>> revision numbers. >>>>>>> If the vote fails, bump the revision number and throw away the old >>>>>>> revision and tag. This is what Tomcat and Httpd do. >>>>>> Can you explain exactly how that works? >>>>> This is the process AIUI: >>>>> >>>>> Tag 7.0.22 from trunk; build, vote. >>>>> >>>>> Vote succeeds - release 7.0.22. >>>>> >>>>> Vote fails, create tag 7.0.23 from updated trunk, build and redo vote >>>>> Tag 7.0.22 could now be deleted, but I think they keep all the tags. >>>>> >>>>> Their achives [1] for 7.0.x don't contain 13, 17, 18; but the tags [2] do. >>>>> >>>>> [1] http://archive.apache.org/dist/tomcat/tomcat-7/ >>>>> [2] http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/ >>>>>> Phil >>>>>>>> Phil >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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 >>>>> >>>> --------------------------------------------------------------------- >>>> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
