Re: [vote] Version for pending release

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