Re: [vote] Version for pending release
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]
Re: [vote] Version for pending release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+1 for #1 On 29-Aug-08, at 9:02 AM, 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] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- Simplex sigillum veri. (Simplicity is the seal of truth.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
I'm +1 for #1. Cheers, Mark 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]
Re: [vote] Version for pending release
the alternative that I see is if we set a cut-off date for features to be complete. if all features for 2.1.0 must be completed in 4 weeks and we leave 4 weeks to stabilize then I don't see the need to give a definitive list of features for 2.1.0 *now*. [however as I am not currently an apache committer, this is just my opinion] I agree that the 2.1 rat hole should be avoided above all Sent from my iPod On 30 Aug 2008, at 03:28, Brian E. Fox [EMAIL PROTECTED] 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? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 12:02 PM To: Maven Developers List Subject: [vote] Version for pending release 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+1 for #1 Dan On Friday 29 August 2008 12:02:12 pm 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 -- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey [EMAIL PROTECTED] 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]
Re: [vote] Version for pending release
On Fri, Aug 29, 2008 at 9:02 AM, John Casey [EMAIL PROTECTED] wrote: Okay, Let's put it to a vote. We have two options: I have a slight preference for #2 since I prefer httpd-style versioning (it's just a number). However, my vote goes to whatever John wants, since he's doing most of the work. :) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
+1 for #1 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Version for pending release
We have a good codebase now, that's not going to rot if it takes a full 72h to decide what to call it. At that point, and after I spin this latest RC12 with the two nasty bugs fixed, it should be basically a formality to vote for the actual release, and we can get this done. It's not 6 months or a year away anymore, it's days away now. Stephen Connolly wrote: I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey [EMAIL PROTECTED] 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] -- 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]
Re: [vote] Version for pending release
+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]
Re: [vote] Version for pending release
I don't mind 72hrs... it's just you forgot to specify how long the vote is open for ;-) Sent from my iPod On 29 Aug 2008, at 17:29, John Casey [EMAIL PROTECTED] wrote: We have a good codebase now, that's not going to rot if it takes a full 72h to decide what to call it. At that point, and after I spin this latest RC12 with the two nasty bugs fixed, it should be basically a formality to vote for the actual release, and we can get this done. It's not 6 months or a year away anymore, it's days away now. Stephen Connolly wrote: I vote that this poll is closed in 48hrs (I only want a decision soon, I dot care which ;-) ) Sent from my iPod On 29 Aug 2008, at 17:02, John Casey [EMAIL PROTECTED] 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] -- 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]
Re: [vote] Version for pending release
OK, OK, you're convincing me. I was just about to write up an e-mail about how we don't have to do it as four codebases: since 2.1.0 would just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put all future bugfixes there. But that'll require a lot of arguing and discussion in the future about the meaning of version names. #1 +1, but with a frowny face. :-( 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]
Re: [vote] Version for pending release
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]
Re: [vote] Version for pending release
FWIW, this will be a standard ASF vote...72h. :-) 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]
Re: [vote] Version for pending release
yeah, the feature-completeness is why I want to stay away from betas on this if we go that route. Betas are supposed to be feature-complete with bugs that are [probably] still in the system...that's not what we have here. Stephen Connolly 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] -- 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]
Re: [vote] Version for pending release
I'm okay with frowny faces... :) Dan Fabulich wrote: OK, OK, you're convincing me. I was just about to write up an e-mail about how we don't have to do it as four codebases: since 2.1.0 would just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put all future bugfixes there. But that'll require a lot of arguing and discussion in the future about the meaning of version names. #1 +1, but with a frowny face. :-( 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] -- 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]
Re: [vote] Version for pending release
Then my vote is advisory as I'm not on the PMC. Ralph John Casey said: FWIW, this will be a standard ASF vote...72h. :-) 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]
Re: [vote] Version for pending release
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 ...
Re: [vote] Version for pending release
+1 to #1 (we can always re-release it as 2.1.0 soon after if that seems better). No objection if we go with #2 either. Concrete opinions: * We should only be maintaining two 2.x branches (one bugfixes, one for features), no more. We need to get them all back into compilable/ IT-passing state ASAP * No new features in 2.1.1, 2.1.2, etc. - move to 2.2. * Keep 2.1.0 close either way (just a small number of pre-selected features as we've discussed already). Thanks John! Cheers, Brett On 30/08/2008, at 2:02 AM, 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] -- Brett Porter [EMAIL PROTECTED] http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [vote] Version for pending release
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? -Original Message- From: John Casey [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2008 12:02 PM To: Maven Developers List Subject: [vote] Version for pending release 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]
