|
»
»
« Return to Thread: [vote] Version for pending release
Re: [vote] Version for pending release
by dfabulich
::
Rate this Message:
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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
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: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: [vote] Version for pending release
| Free embeddable forum powered by Nabble | Forum Help |
