maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Fedorenko <i...@ifedorenko.com>
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.

--
Regards,
Igor

On 11-12-05 9:33 AM, Stephen Connolly wrote:
> 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<igor@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<mfriedenhagen@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<brianf@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/%3C2BABBE7D2A66E04DB8A66A527D29927E35E489@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-unsubscribe@maven.apache.org>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<dev-unsubscribe@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<dev-unsubscribe@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message