<friday evening> Maven 1 ? Ohh no, not it !!!!!!!!! </friday evening>
On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly < [EMAIL PROTECTED]> wrote: > I think m1 is more concrete than a beta, while signalling that it's not > feature complete > > Sent from my iPod > > > On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED]> > wrote: > > +0.99 for 1 >> +0.01 for 2 >> >> I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would >> prefer 2.1.0-beta-1 >> I don't have found any document stating which pre x.y.z (with x, y, z >> integers) standard maven follows. >> >> Raphaël >> >> >> 2008/8/29, John Casey <[EMAIL PROTECTED]>: >> >>> 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] > > -- .......................................................... Arnaud HERITIER .......................................................... OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .......................................................... ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...........................................................
