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