Hello everybody, I understand the need to distinguish between these attempts. I now have a local copy of 3.0.4 on my disc (as well as on some others). Next month forgetful as I am, I will not know anymore which of the different 3.0.4 copies was the blessed one. Let alone that the tag in subversion will have nothing to do with the real thing.
On the other hand I do not like having things named 3.0.4-RC1..10 and when RC10 should be the "good" version then we try to rebuild this perfectly behaving binary once again just with a different name and break it again possibly while doing this. Here at work I try to convince my coworkers to always increase version numbers while tagging a new version, even if the change is "really small". A name already taken is burnt IMO. What about introducing a fourth number (3.0.4.N) without any special semantics. Then we all could test the 3.0.4.2, would be sure we talk about the same thing (instead of "the first of the attempts to release 3.0.4, you know, the one version we had to draw back" which is not the same as "the second attempt to release 3.0.4, you know, the second version we had to draw back" ... ;-)). and when the vote passed this version 3.0.4.N would be "released" by communicating this to the user list and modifying the link on http://maven.apache.org/ Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Mon, Dec 5, 2011 at 01:44, Brian Fox <bri...@infinity.nu> wrote: >> Again I start a release process and produce a "candidate for release" >> build with a naming 3.0.4 for 5 days vote. >> Something failed, so it has been fixed and I restarted a vote with a >> second "candidate for release" called 3.0.4 for 5 days vote. >> (retagging etc.... ) >> >> What is the difference with producing something called RC1 (build >> which will never published) and rebuild after some days the SAME thing >> without the RC end naming ? >> >> Sorry but except some marketing naming I don't see any difference in a >> technical point of view (everything can be tracked in the scm). > > There's a big difference as we found in the past. > > Quoting from myself > (http://www.sonatype.com/people/2008/04/quality-is-not-accidental/) > > "The normal release process for Maven is to stage a release, email the > dev list and wait for votes or show stopper issues to occur. The norm > for most releases is 72 hours, but with Maven core releases it was > common to let it bake for a week or more. Based on history, I was > positive that the first few attempts wouldn’t make it through, so we > started with a “pre vote” instead of a vote email. > > It seemed that each “pre vote” staged release we posted for dev list > testing showed yet another how come no one noticed that? regression. > It became apparent that we needed more than ever to harness the power > of the full community to squash these regressions. Since tossing out > multiple versions all called “2.0.9″ to such a wide audience was > clearly a bad idea, we started appending -RC[x] to distinguish them. > Additionally, we needed to have a set of operating parameters to guide > this broad level of testing, lest we have chaos in the flood of bug > fix requests." > > The point is we need to put something out that is a "release" that the > wider user community will consume and provide feedback on. This has in > the past been very effective at surfacing important issues that won't > be found from people on the dev list, but will be found before the ink > is even dry on the official release. > > You can see more of the reasoning here: > http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E > > This has pretty much been standard fare since 2.0.9, and I don't see a > good reason to deviate. On the contrary, wagon changes are > particularly hard to fully test out and having more eyes are better. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
