Totally agreed, my point was uniqueness and reproducabilty, so 3.0.5 etc. would be perfect IMO.
Regards Mirko -- Sent from my phone http://illegalstateexception.blogspot.com http://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Dec 5, 2011 3:18 PM, "Stephen Connolly" <[email protected]> wrote: > 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 <[email protected] > >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 <[email protected]> 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/%[email protected]%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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
