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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
