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]
