Bojan Smojver wrote:
Quoting Glenn <[EMAIL PROTECTED]>:
-0.5 to using odd for stable, and even for development
The model of parallel stable and development branches is similar to
numerous other projects, including the Linux kernel and Perl, except that
the meaning of the sub-version numbers is **reversed** in Bill's proposal.
While I am not saying we should copy the Linux and Perl versioning "just
because", I am suggesting that it is counter-intuitive and confusing to
end-users (and suits!) who are familiar with them. Therefore, I would
like to see X.even == stable and X.odd == development.
To me, as an Apache user (and would-be developer), this makes sense. Why not tag
the current CVS head as 2.1.0 (unstable) and then work towards a stable 2.2?
This would achieve two goals within the user/developer community:
- show them that the versioning system changed and give them time to get used to
it by spreading the word
- let them now that the time to break the API is now, if they want the change to
appear in the next stable release
- look forward (positively) to the next "stable stable" release, which will even
guarantee a great deal of binary compatibility
- make significant psychological impact with 2.2 as compared to 2.0, which would
convey the meaning of "stable stable" release more convincingly
- let them know that the moment 2.2 has settled, the new development branch will
be created (2.3)
Okay, I finally caught up on all this. Here's my 2 cents worth...
I am *very* much in favor of providing a stable location to make 3rd party
developers and end users comfortable while providing a parallel dev location for
the new and possibly unstable work to be happening.
With a small amount of cleanup/polish, I think the ROADMAP looks great. We can
hash out the details over the next days/weeks.
I also agree with Bojan above, but would like to offer one added twist...
there is some question about odd=stable vs. even=stable. I would submit that we
go with the following:
X.0.y = wild, wooly, no-holds-barred, pie-in-the-sky, dreamland. Feel free
to completely redesign the world, introduce new models, change the
whole way internals work, whatever...
Then, when the dust starts to settle and the wild becomes more mild...
X.1.y = Becomes the first serious development stream. We have a direction,
a solid base to build from, and a certain level of stability for
developers to trust. Things can change (including APIs and MMN), but
there are some limits (i.e. 2.1 would not decide to use another
portability layer...)
From that point on X.odd.y=dev, X.even.y=stable and follows the rules of
the ROADMAP...
X.0.y is always special because it signifies a dramatic shift in concepts for
a product. Handling X.0.y in the way described above officially recognizes why
most people are leary of X.0.y releases. It gives folks the opportunity to have
total freedom of design. Then, once there has been a proof of concept, the
prototype is working well, and there is a clear direction, we move it into an
official X.1.y development stream. In *theory* we could start a new X+1.0.y
stream as soom as we create a X.1.y stream.
In essence, this is how 2.0 came about. Several different sandboxes existed. Once
things settled down and we decided on Apache+APR, that became the development path.
The difference is, according to my comments above, we should have moved to 2.1
when 2.0 became an acceptable and stable proof of concept with a clear direction.
Our first GA would have resulted in creation of 2.2-stable and 2.3-dev.
Anyway, the long and short of it is, I like the parallel streams, I like the
rules setup in the ROADMAP, I like odd=dev and even=stable, and I like officially
recognizing the wild, unstable, and fun nature of X.0.y.
--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it. Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein
