As I said before, I very much agree with this.
Ralph
John Casey wrote:
Releasing the current RC work is exactly what I was proposing, and
what I am proposing now. The only difference was that I changed my own
perspective on this a little...if we're not introducing new features,
there is very little to distinguish this RC code from the code in
2.0.x. Further, if we plan to introduce new features next, then we're
really talking about having 2.0.x and 2.1.0 be basically the same, no
new features for 2.1.1 since that's bad juju, and then, in 2.2, we
finally get some new features.
I guess I see that as a little awkward. Agreed, the work we've done
leading up to this RC process (and into it) has changed quite a bit of
code, but part of why this RC process has been so long is that we're
taking great care to make sure it's fully backward compatible. If we
were bringing huge gains in terms of fixing horrible bugs with this
code, I'd say that 2.1.0 is great, and any regressions found there
could go in 2.1.1, etc. But the worst things we're really fixing in
this release is performance (it's better than 2.0.9, not that 2.0.9
was that horrible) and regressions caused by the release of 2.0.9.
I'm gambling that the version 2.1.0-M1 won't be too big of a
psychological hit to keep people from using it; maybe that's off
target. In any case, I was hoping that by declaring this a M1 and
immediately setting up a 2.1.0 release plan (hopefully before calling
the vote for M1), that we could keep things on track, get new features
for 2.1.0, and avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the
works at the same time. From my experience of the activity levels in
this project, that would be overreaching. Hell, we have plugins that
need work and that are pretty badly neglected right now.
WDYT?
-john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
