So you mean that instead of e.g. 2.2-alpha, 2.2-beta, 2.2-rc and 2.2.0 we would have 2.3.0, 2.3.1, 2.3.2 and then 2.4.0 for the stable release? And then 2.4.1 for bug fixes?
Yes, this is how the linux kernel works:
major.odd-minor.release -> development major.even-minor.bugfix -> stable
Note how this removes the need to think in "alpha/beta/rc/final" which is very nice, IMO, I never liked those staging paradigms.
As much as I agree that using odd/even numbers to identify meaning is odd, I think it worked very well for linux and I don't see why it shouldn't work for us.
It follows a mental picture that many already have (and, besides, I think HTTPD is following this too)
Considering how things are going in cocoon-land, I guess we'll have a flurry of even numbers because new features are introduced along with bugfixes all the time.
This odd/even numbering scheme applies well IMO for very focused projects but not for the constant evolution and refinement of our large code base. Things may change however with the introduction of real blocks, as each block will live its own life independently and the kernel and core are likely to evolve less.
This is exactly my opinion. If we cannot apply this versioning scheme, it doesn't mean that the scheme is not working, it means that our distribution model if flawed.
To sum up, my opinion is : - why not once we have blocks and each block has its own version numbering - it won't fit with the current single large code base we have today
sounds reasonable to me.
-- Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
