Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc version numbers are cheap...
if anyone asks what happend to 3.0.4, we just say, oh that was not released, there's a tag of it in svn, but there are no binaries or source distributions because it failed for some reason. On 5 December 2011 13:46, Mirko Friedenhagen <mfriedenha...@gmail.com>wrote: > 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 > >
