IMO, the change in version scheme could be a very positive thing, as it
emphasizes introducing a feature at a time instead of pushing them all
in and claiming that everything is mostly working with some bugs. I
think this may help us manage the chaos that comes from introducing
these sorts of things.
Also, IMO it's going to be a hard sell getting people to go 2.0.9 ->
2.1.0 when there is no compelling reason for the change in minor version
number. Sure, there are stability and performance improvements, but it's
all guts to users, and I'm guessing more than one will wonder at what
cost the performance improvements come. Remember, this isn't the first
time we've done a release on the basis of stability improvement; IMO we
have a little bit of a credibility deficit there. :-)
-john
Dennis Lundberg wrote:
My personal preference is #2
The reasoning behind this is that we'd be introducing yet another
versioning scheme into the mix that we already have. This might be
confusing to our users and as John hinted at might not attract as many
users.
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]
