I've moved the discussion to the new thread as to not mismatch two different topics
2011/12/17 Martin Cooper <mart...@apache.org>: >> As a follow up, I've added one more point to the Release guide [1], is >> it enough ? > > That looks fine, as long as everyone is in agreement. > > The question in my earlier message was just that - a question. The > answer, after digging around in the archives, appears to be yes, we > did stop doing that, quite some time ago, and somehow I never noticed > until now. As far as I can tell, we didn't make a conscious decision > to change; it just happened one time when somebody took on the release > task. Nobody noticed, and we've kept doing it that way ever since. > > As for which way we do it going forward, it really depends on how > quickly people - PMC members especially, but not only PMC members - > feel they can test a new build. It is *very* important that people > vote, and test prior to it, based on the actual bits posted by the RM; > not their own build, or a recent snapshot they may have downloaded. If > enough people believe they can pick up a new build immediately, > incorporate it into their own environment, test it thoroughly, and > then vote, all within 72 hours, then there shouldn't be a problem with > continuing the way we have been. If that seems a bit tight, then we > should leave some time for testing before calling the vote. I'm wondering how to proceed to release BETA1, BETA2, ..., RC1, RC2, ...., GA versions. With the current approach the name of packages must be specified during running mvn release:prepare command, even if we decide to call it Beta during a Vote it isn't possible to rename the artifacts, Subversion Tag and so on. And to meet the result of the Vote, a new mvn release:prepare command must be issued and a new Vote called (as we vote over the exact bits) - the whole release process must be started over. Do I miss something ? Kind regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ Warszawa JUG conference - Confitura http://confitura.pl/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
