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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
