[vote] Version for pending release

[Dennis Lundberg-2]

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
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mauro Talevi]

Brian E. Fox wrote:
> Until I see a definitive list of the Milestones for 2.1, I vote for #2.
> I am mostly afraid of going down the rat hole that was the old 2.1 with
> forever changing scope. I don't see any problem with calling this 2.1
> and putting in the other features into 2.2, what's the problem?
>

My vote is for #2, as IMO the advantages outweigh the disadvantages
pointed out by John.

As Brett stressed, anything that has new features should warrant a new
2.x release and bugfixes should go in 2.x.y.

Cheers


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mihobson]

I'm +1 for #1.

Cheers,

Mark

2008/8/29 John Casey <jdcasey@...>:

> 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@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dennis Lundberg-2]

As others have said before, since you John are the one doing most of the
work on this I trust your judgement in choosing the best option.

John Casey wrote:

> 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
>>>
>>
>>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

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@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

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 <jdcasey@...> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...