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
