[vote] Version for pending release

[Stephen Connolly-2]

afaik, I did not vote for any option (just a time bounded vote) ;-)

Sent from my iPod

On 3 Sep 2008, at 19:22, John Casey <jdcasey@...> wrote:

> The result was:
>
> #1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
>    2 non-binding: Ralph, Raphael
>
> #2: 2 binding: Brian, Dennis
>    2 non-binding: Mauro, Stephen
>
> If you're following the other thread ("Maven 2.1.0 GA Plan") you'll  
> see that I've started to formalize the suggestions I made for  
> features to be included in 2.1.0 in Confluence. This is by no means  
> set in stone; in fact, for two of the features, we're still waiting  
> on design documentation before I'm comfortable committing to them.
>
> I'd like to know if anyone would like to put a different issue on  
> the plan, and/or maybe talk about bumping one or more of these  
> features to 2.2...in short, I was hoping to solicit some discussion  
> about what we're going to be building for 2.1.0.
>
> Thanks,
>
> -john
>
> John Casey wrote:
>> 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@...
> For additional commands, e-mail: dev-help@...
>

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

[John Casey-5]

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@...
For additional commands, e-mail: dev-help@...

[dkulp]

+1 for #1

Dan



On Friday 29 August 2008 12:02:12 pm John Casey wrote:

> 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

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

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

[Stephen Connolly-2]

I vote that this poll is closed in 48hrs (I only want a decision soon,  
I dot care which ;-) )

Sent from my iPod

On 29 Aug 2008, at 17:02, John Casey <jdcasey@...> wrote:

> 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@...
> For additional commands, e-mail: dev-help@...
>

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

[Wendy Smoak-3]

On Fri, Aug 29, 2008 at 9:02 AM, John Casey <jdcasey@...> wrote:
> Okay,
> Let's put it to a vote. We have two options:

I have a slight preference for #2 since I prefer httpd-style
versioning ("it's just a number").

However, my vote goes to whatever John wants, since he's doing most of
the work. :)

--
Wendy

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

[John Casey-5]

We have a good codebase now, that's not going to rot if it takes a full
72h to decide what to call it. At that point, and after I spin this
latest RC12 with the two nasty bugs fixed, it should be basically a
formality to vote for the actual release, and we can get this done.

It's not 6 months or a year away anymore, it's days away now.

Stephen Connolly wrote:

> I vote that this poll is closed in 48hrs (I only want a decision soon, I
> dot care which ;-) )
>
> Sent from my iPod
>
> On 29 Aug 2008, at 17:02, John Casey <jdcasey@...> wrote:
>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

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

[Ralph Goers]

+1 for #1

John Casey wrote:

> 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
>

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

[Raphaël]

+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@...>:

> 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@...
>  For additional commands, e-mail: dev-help@...
>
>

[jvanzyl]

+1 for #1

On 29-Aug-08, at 9:02 AM, John Casey wrote:

> 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@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

Simplex sigillum veri. (Simplicity is the seal of truth.)


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

[Stephen Connolly-2]

I don't mind 72hrs... it's just you forgot to specify how long the  
vote is open for ;-)

Sent from my iPod

On 29 Aug 2008, at 17:29, John Casey <jdcasey@...> wrote:

> We have a good codebase now, that's not going to rot if it takes a  
> full 72h to decide what to call it. At that point, and after I spin  
> this latest RC12 with the two nasty bugs fixed, it should be  
> basically a formality to vote for the actual release, and we can get  
> this done.
>
> It's not 6 months or a year away anymore, it's days away now.
>
> Stephen Connolly wrote:
>> I vote that this poll is closed in 48hrs (I only want a decision  
>> soon, I dot care which ;-) )
>> Sent from my iPod
>> On 29 Aug 2008, at 17:02, John Casey <jdcasey@...> wrote:
>>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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

[dfabulich]

OK, OK, you're convincing me.  I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would just
be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put
all future bugfixes there.  But that'll require a lot of arguing and
discussion in the future about the meaning of version names.

#1 +1, but with a frowny face. :-(

John Casey wrote:

> 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@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Stephen Connolly-2]

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@...> 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@...>:
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>>

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

[John Casey-5]

FWIW, this will be a standard ASF vote...72h. :-)

John Casey wrote:

> 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@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

yeah, the feature-completeness is why I want to stay away from betas on
this if we go that route. Betas are supposed to be feature-complete with
bugs that are [probably] still in the system...that's not what we have here.

Stephen Connolly 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@...>
> 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@...>:
>>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

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

[John Casey-5]

I'm okay with frowny faces... :)

Dan Fabulich wrote:

> OK, OK, you're convincing me.  I was just about to write up an e-mail
> about how we don't have to do it as four codebases: since 2.1.0 would
> just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0,
> and put all future bugfixes there.  But that'll require a lot of arguing
> and discussion in the future about the meaning of version names.
>
> #1 +1, but with a frowny face. :-(
>
> John Casey wrote:
>
>> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

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

[Ralph Goers]

Then my vote is advisory as I'm not on the PMC.

Ralph


John Casey said:

> FWIW, this will be a standard ASF vote...72h. :-)
>
> John Casey wrote:
>> 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@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Arnaud HERITIER]

<friday evening>
Maven 1 ? Ohh no, not it !!!!!!!!!
</friday evening>

On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly <
stephen.alan.connolly@...> 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@...>
> 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@...>:
>>
>>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
..........................................................
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
...........................................................

[brettporter]

+1 to #1 (we can always re-release it as 2.1.0 soon after if that  
seems better).

No objection if we go with #2 either.

Concrete opinions:
* We should only be maintaining two 2.x branches (one bugfixes, one  
for features), no more. We need to get them all back into compilable/
IT-passing state ASAP
* No new features in 2.1.1, 2.1.2, etc. - move to 2.2.
* Keep 2.1.0 close either way (just a small number of pre-selected  
features as we've discussed already).

Thanks John!

Cheers,
Brett

On 30/08/2008, at 2:02 AM, John Casey wrote:

> 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@...
> For additional commands, e-mail: dev-help@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Brian E Fox]

Until I see a definitive list of the Milestones for 2.1, I vote for #2.
I am mostly afraid of going down the rat hole that was the old 2.1 with
forever changing scope. I don't see any problem with calling this 2.1
and putting in the other features into 2.2, what's the problem?

-----Original Message-----
From: John Casey [mailto:jdcasey@...]
Sent: Friday, August 29, 2008 12:02 PM
To: Maven Developers List
Subject: [vote] Version for pending release

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@...
For additional commands, e-mail: dev-help@...


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

[Stephen Connolly-2]

the alternative that I see is if we set a cut-off date for features to  
be complete. if all features for 2.1.0 must be completed in 4 weeks  
and we leave 4 weeks to stabilize then I don't see the need to give a  
definitive list of features for 2.1.0 *now*.

[however as I am not currently an apache committer, this is just my  
opinion]

I agree that the 2.1 rat hole should be avoided above all

Sent from my iPod

On 30 Aug 2008, at 03:28, "Brian E. Fox" <brianf@...>  
wrote:

> Until I see a definitive list of the Milestones for 2.1, I vote for  
> #2.
> I am mostly afraid of going down the rat hole that was the old 2.1  
> with
> forever changing scope. I don't see any problem with calling this 2.1
> and putting in the other features into 2.2, what's the problem?
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@...]
> Sent: Friday, August 29, 2008 12:02 PM
> To: Maven Developers List
> Subject: [vote] Version for pending release
>
> 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@...
> For additional commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

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