Sylvain Wallez wrote:
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.
Mmmh... I quite like them on the contrary, since they give an image of the "level of confidence" the developer team has in a particular release, and how users can rely on it.
Now I agree that this is highly subjective and can have very different meanings depending on the projects. Having numbers only forces people to look at the release notes and make the decision by themselves.
It can however refrain more people to use "unstable" versions (per their version numbers) since they don't know how close to stable they are, and then lead us to doing a "stable" release that hasn't been shaked enough and lead to numerous bug reports, and hence "stable" versions. But that may be an acceptable way also (release early, release often).
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.
And this 2.1.5 release show it very well, with the fact that lots of people were expecting a stable CForms. We clearly have a conflict between the need to release bugfixes on the core and stable blocks, whereas some highly awaited blocks are still marked unstable.
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.
Cool :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
