maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arnaud HERITIER" <aherit...@gmail.com>
Subject Re: [vote] Version for pending release
Date Fri, 29 Aug 2008 21:24:55 GMT
<friday evening>
Maven 1 ? Ohh no, not it !!!!!!!!!
</friday evening>

On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> I think m1 is more concrete than a beta, while signalling that it's not
> feature complete
>
> Sent from my iPod
>
>
> On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <raphaelpieroni@gmail.com>
> wrote:
>
>  +0.99 for 1
>> +0.01 for 2
>>
>> I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would
>> prefer 2.1.0-beta-1
>> I don't have found any document stating which pre x.y.z (with x, y, z
>> integers) standard maven follows.
>>
>> Raphaël
>>
>>
>> 2008/8/29, John Casey <jdcasey@commonjava.org>:
>>
>>> Okay,
>>>
>>> Let's put it to a vote. We have two options:
>>>
>>> 1. Release the current release candidate as milestone 1 of the 2.1.0
>>> codeline. The version for this release would be 2.1.0-M1.
>>>
>>> The advantage of this approach is that it keeps is (relatively) focused
>>> on
>>> only three simultaneous codebases, not four. It provides a stable
>>> foundation
>>> for building out a small set of new features for a final GA release of
>>> 2.1.0. This release will have no new features, and its only goal is
>>> backward
>>> compatibility with the maximum stability possible. To me, this isn't
>>> enough
>>> to distinguish it from 2.0.x. However, the implementation details are
>>> such
>>> that it deserves to be separate.
>>>
>>> The disadvantage is that a -M1 release may not attract as many users, and
>>> the performance/stability gains may not be compelling enough to overcome
>>> the
>>> psychological barrier of moving from 2.0.9 to 2.1.0-M1.
>>>
>>> 2. Release the current release candidate as 2.1.0 GA.
>>>
>>> The advantage here is that the work we've put into stabilizing this RC is
>>> probably more worth of a GA release, and by calling it 2.1.0 we can tell
>>> our
>>> users how solid we think it is. Additionally, calling this 2.1.0 means
>>> that
>>> the only thing we could do for 2.1.1, 2.1.2, etc. would be to fix any
>>> regressions that cropped up without adding risk from new features.
>>>
>>> The major disadvantage is that it will mean that some of us are adding
>>> new
>>> features to 2.2.0 (parent-versioning, reactor changes, etc.) while others
>>> are trying to push out regression fixes on 2.0.x and 2.1.x, while still
>>> others are introducing large-scale changes on the 3.0.x branch. I'm
>>> personally not sure we can drive four parallel codelines to release in a
>>> timely manner.
>>>
>>> So, let's vote. Just indicate whether you support #1 or #2.
>>>
>>> My vote is for #1.
>>>
>>> Thanks,
>>>
>>> -john
>>>
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: 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
>
>


-- 
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message