Hi folks, some thoughts along the line ...
+) I would like to use the M2 release plugin +) I don't mind copying the release tag to a "RCX SVN" tag if the vote fails +) the <commons.rc.version> is work-around to distinguish multiple RCs +) I know that the release process is not perfect but "perfect is the enemy of good" And my personal point of view - either we settle for one (documented and accepted) approach or you should positively accept that not all things are perfect. At the end of the day I want to get a release out of the door and not let my RC getting killed by endless discussion (btw - the last time it was the version numbering schema for commons-exec) Thanks in advance, Siegfried Goeschl Mark Struberg wrote: > I assume 'cutting a release' as doing a mvn release:stage or something > similar. The release artifacts will only be pushed to the public repos and > download areas etc. after the vote has finally passed. > > The way this works basically moves all the effort to the last RC-n voting > step. It is utterly important that all reviewers treat each RC-n vote as if > it would be a release vote, because it actually IS a real release vote! > > Checking out the last RC-n and tagging it with a final release tag is only > for marking it as 'this is the final release version'. Since all the reviews > should have been done, it is very unlikely that this gets cancelled. > > LieGrue, > strub > > --- Jochen Wiedmann <jochen.wiedm...@gmail.com> schrieb am Mo, 29.6.2009: > > >> Von: Jochen Wiedmann <jochen.wiedm...@gmail.com> >> Betreff: Re: svn commit: r788761 - /commons/proper/email/tags/EMAIL_1_2/ >> An: "Commons Developers List" <dev@commons.apache.org> >> Datum: Montag, 29. Juni 2009, 12:22 >> What do you mean by "cutting a >> release"? If this means building the >> distribution files, then your points 3.) and 4.) are a >> contradiction. >> >> Jochen >> >> >> On Mon, Jun 29, 2009 at 12:14 PM, Mark Struberg<strub...@yahoo.de> >> wrote: >> >>> I personally don't get all the discussion here, >>> >> because this very question has imho been discussed a lot in >> the past (on commons and maven lists). >> >>> From what I know the widely agreed output of this >>> >> discussion has been: >> >>> 1.) do n PRJ-x-RC-n before cutting a release and vote >>> >> on them as if they were final. >> >>> 2.) If the vote fails, create a PRJ-x-RC-(n+1) and >>> >> redo the vote. >> >>> 3.) once the vote has passed, take the last PRJ-x-RC-n >>> >> tag and based on this cut a release PRJ-x. >> >>> 4.) If and only if there is a show stopper with PRJ-x >>> >> we have to delete the tag in the SVN. But this situation >> should really not appear in praxis since the PRJ-x-RC-n has >> been reviewed already! >> >>> And btw, the ONLY binding delivery of ASF is the >>> >> signed source.tar.gz and not the SVN tag. So deleting a tag >> in SVN (although highly undesirable) imho isn't strictly >> forbidden. >> >>> So anyone willing to explain me what the problem is >>> >> now? >> >>> txs and LieGrue, >>> strub >>> >>> >>> --- Jochen Wiedmann <jochen.wiedm...@gmail.com> >>> >> schrieb am Mo, 29.6.2009: >> >>>> Von: Jochen Wiedmann <jochen.wiedm...@gmail.com> >>>> Betreff: Re: svn commit: r788761 - >>>> >> /commons/proper/email/tags/EMAIL_1_2/ >> >>>> An: "Commons Developers List" <dev@commons.apache.org> >>>> Datum: Montag, 29. Juni 2009, 7:37 >>>> On Mon, Jun 29, 2009 at 12:13 AM, >>>> sebb<seb...@gmail.com> >>>> wrote: >>>> >>>> >>>>> Are you sure that is the case? >>>>> >>>>> The Commons release wiki page implies that >>>>> >> one can >> >>>> provide the RC number as in >>>> >>>>> >> <commons.rc.version>RC2</commons.rc.version> >> >>>> Obviously commons has managed to introduce yet >>>> >> another >> >>>> peculiarity in >>>> its release process ... I have to admit that I >>>> >> don't know >> >>>> what this >>>> thing does. >>>> >>>> The important part, from my point of view, is that >>>> >> I'd like >> >>>> to reuse >>>> all the standards and procedures that Maven itself >>>> >> uses >> >>>> (subject to >>>> the same legal rules and policies we must follow >>>> ourselves), and >>>> concentrate on the projects contents, rather than >>>> >> have >> >>>> anything >>>> special. In particular, because I have followed >>>> >> the process >> >>>> from >>>> >>>> http://maven.apache.org/developers/release/releasing.html >>>> >>>> twice (Rat 0.6 and XML-RPC 3.2) and found it >>>> >> incredibly >> >>>> smooth and >>>> easy to go: A real advancement. >>>> >>>> Just the fact that we have our own release >>>> >> document, which >> >>>> is much >>>> more complex than the above document, rather than >>>> >> mostly >> >>>> just >>>> referring to it, speaks for itself. >>>> >>>> Jochen >>>> >>>> >>>> -- >>>> Don't trust a government that doesn't trust you. >>>> >>>> >>>> >> --------------------------------------------------------------------- >> >>>> 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 >>> >>> >>> >> >> -- >> Don't trust a government that doesn't trust you. >> >> --------------------------------------------------------------------- >> 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
