You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2008/08/24 07:58:41 UTC
Re: [RESULT] [vote] Version for pending release
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 <jd...@commonjava.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [RESULT] [vote] Version for pending release
Posted by John Casey <jd...@commonjava.org>.
Fair enough, I misunderstood. :)
Stephen Connolly wrote:
> 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 <jd...@commonjava.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org