On Mon, Dec 19, 2011 at 2:49 AM, Rene Gielen <gie...@it-neering.net> wrote: > 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).
Yup. It's probably worth reiterating here that the word "release" is unfortunately imbued with two meanings. There is "release" in the Maven sense of the word, which is essentially just a way of building a package and pushing it places. And then there is "release" in the ASF sense of the (GA / Beta / Alpha) artifact that the Struts PMC is responsible for. The former sense does not imply the latter. We just happen to use the former for our build mechanics. >> >> 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 Actually, no, not quite. A really, really long time ago, with early Struts 1 releases, we used to designate quality with the initial build. We got out of that bad habit quite a few years ago. The process I was referring to, which was used for later Struts 1 and earlier Struts 2 builds, was: - RM: Perform the (Maven) release process using next build number. - RM: Announce a new Test Build. - RM: Wait for about a week to give everyone a chance to download and test it. - All: Download, test, and provide feedback if appropriate. - RM: If no show-stoppers reported, start a vote thread for build quality designation. - All: Vote on quality - GA, Beta, Alpha, or just stay at test build. - RM: If the vote result is for an ASF release (i.e. not test build), update site, announce - RM: If the vote result is for GA, push to central Note that the *only* difference between the process above, and what we have been doing since we changed it, is the week-long wait to allow everyone in the community enough time to test the test build before a vote is called. Otherwise the process is identical. Really! -- Martin Cooper > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
