afaik, I did not vote for any option (just a time bounded vote) ;-)
Sent from my iPod
On 3 Sep 2008, at 19:22, John Casey <[EMAIL PROTECTED]> wrote:
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-binding: Ralph, Raphael
#2: 2 binding: Brian, Dennis
2 non-binding: Mauro, Stephen
If you're following the other thread ("Maven 2.1.0 GA Plan") you'll
see that I've started to formalize the suggestions I made for
features to be included in 2.1.0 in Confluence. This is by no means
set in stone; in fact, for two of the features, we're still waiting
on design documentation before I'm comfortable committing to them.
I'd like to know if anyone would like to put a different issue on
the plan, and/or maybe talk about bumping one or more of these
features to 2.2...in short, I was hoping to solicit some discussion
about what we're going to be building for 2.1.0.
Thanks,
-john
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]
