On 21 October 2010 16:02, Rainer Jung <rainer.j...@kippdata.de> wrote: > On 21.10.2010 14:48, Mladen Turk wrote: >> >> On 10/21/2010 02:29 PM, Rainer Jung wrote: >>> >>> On 21.10.2010 09:02, Mladen Turk wrote: >>>> >>>> Hi, >>>> >>> >>> Hmmm, the problem with the RCs is: >>> >>> - either we don't want to change any contents of the release between >>> the last RC and the release. Then the RCs do not contain any >>> indication that they are actually RCs. So they might circulate and >>> actually look like an official release. >>> - or we add RC1 or whatever somewhere to the files and version >>> strings. Then we have to reroll after the RC finally is approved (and >>> I think to vote again) >>> >> >> Why? >> I mean tag something like _RC1 if voted fine, just rename the tag to >> release. >> It will contain the same thing in there no mater what trunk points to. >> If not create fixes in the trunk, create _RC2 tag and iterate again. >> >> svn mv is just a handy tool for that. >> If you want't to keep the _RC1 (for what ever reason) then >> just do a svn cp 1.2.31_RC1 1.2.31 > > My point is: once we circulate something, it should be clearly > distinguishable from anything else we start to circulate. If the RC doesn't > contain in it any indication of RC, you will never be able to tell, whether > someone is using an RC1, RC2 or final release. All of them will identify > itself as 1.2.31. > > Previously we circulated clearly distinguishable versions to do some pre > voting testing and when we had the impression it looks good, we rolled the > final version and voted. > > The other way would be like TC does it, namely tag a version and if it fails > tag a new version. I did like our previous approach better. I'm not very > comfortable with the possibilities of having RC1, RC2 etc. all of them > identifying themselves as the real release.
If the archives contain the RCn suffix, would that not be sufficient? The archives should not be put on general release, so it would only be reviewers that have copies and they should know. If you wish to distinguish the contents, then one possible solution is to include the SVN revision somewhere in the code. That would be useful anyway. Also, any separately released items need to have hashes and sigs, so one can distinguish the files if necessary. > > Regards, > > Rainer > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
