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
