But we have never made the RCs available from Maven Central. http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven%22%20AND%20a%3A%22maven-core%22
Show me an RC version in that list! On 5 December 2011 14:30, Igor Fedorenko <i...@ifedorenko.com> wrote: > This approach fails to make the release candidate available to a wider > community. We need to make release candidate builds available for > download and from maven central repository so early adopters can try > them easily. But we also need to have release candidates clearly marked > as such so more conservative users know what they are. Reputation of a > quality project takes very long time to build but can be lost in a one > or two rushed releases. > > -- > Regards, > Igor > > > On 11-12-05 9:17 AM, Stephen Connolly 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<mfriedenhagen@**gmail.com<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/<http://illegalstateexception.blogspot.com/> >>> https://github.com/**mfriedenhagen/ <https://github.com/mfriedenhagen/> >>> https://bitbucket.org/**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/<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/% >>> **3C2BABBE7D2A66E04DB8A66A527D29**927E35E489@intrepid.infinity.**nu%3E<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-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> ------------------------------**------------------------------** >>> --------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >>> >> > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@maven.apache.**org<dev-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
