maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <>
Subject Re: RC release naming (was Re: [VOTE] Apache Maven 3.0.4 (take 2) )
Date Mon, 05 Dec 2011 14:43:39 GMT
Fair enough. I confused RC with alpha/beta versions we had in the past.
I can't recall if RCs were available from download page, though.


On 11-12-05 9:33 AM, Stephen Connolly wrote:
> But we have never made the RCs available from Maven Central.
> Show me an RC version in that list!
> On 5 December 2011 14:30, Igor Fedorenko<>  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@**<>
>>>> 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, 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
>>>> Regards Mirko
>>>> --
>>>> http://illegalstateexception.**<>
>>>> On Mon, Dec 5, 2011 at 01:44, Brian Fox<>   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
>>>>>> 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
>>>>>> 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
>>>>> (**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<>
>>>>> This has pretty much been standard fare since 2.0.9, and I don't see
>>>>> 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<>
>>>>> For additional commands, e-mail:
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<>
>>>> For additional commands, e-mail:
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<>
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message