On Mon, 19 Dec 2011 09:35:33 +0100, Łukasz Lenart <lukasz.len...@googlemail.com> wrote: > Thanks for clarification but I'm still not sure if I get it right ;-) > > So I can start a new release process as soon I want to but it can be > called an Alpha/Beta/GA build only because of Vote result ? I cannot > predetermine the result and say "hey, lets release Beta1" ?
Currently what we are doing is performing a release build - which just means releasing in terms of technical lifecycle management, thus building and releasing a non-SNAPSHOT version - and then announce it for testing/voting. From our process perspective this is a release candidate. The feedback from the vote determines what quality grade we rate it, most notably whether we see it ready for primetime or still in Beta (or less, if fundamentally broken). > > And if during the Vote, the result is different than GA should the > site and so on be published ? > If say 2.3.2 is voted for GA quality, we announce it as GA and push it to central. If on the other hand it would be rated as Beta, we basically don't push it to central. Currently we are just announcing a vote result, we *could* as well go and announce a Beta build to the lists and to http://struts.apache.org/downloads.html (which actually contains a section for that). The next possible GA release now is 2.3.3, because 2.3.2 is technically released (as a Beta) and the next shot needs a new unique version. And on it goes ... An important thing to remember is that we decided against version tags such as 2.3.2-Beta-1, since this implies having to go through the whole technical release process, including full testing, for the 2.3.2-GA version. That said, what Martin referenced as the process we used to have was basically - performing 2.3.2 release process - announce a Beta - wait - if no show-stoppers reported, cast a vote - test, if not done in the Beta phase (!!!) - if the vote result says GA, go for publishing If we feel that this is the better / cleaner process, we can document and switch to it, of course. - René --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
