2011/12/5 Stephen Connolly <[email protected]>: > 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. agree even if it's pretty similar to 3.0.4-RCn :-)
BTW it's too late I have staged a 3.0.4-RC3 (it was very difficult for me to choose RC1 or RC3 :-) ). At least in a technical POV providing different number, is better to prevent various MRM which cache release artifacts. For people consuming those artifacts, it can be a pain to cleanup a chain of cached artifact. So let concentrate on coding (improvement and issue fixes rather than such non end discussions as probably never everybody will agree :-) IMHO ). > > 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] >> >> -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
