Appended is the first version of the versioning guide. I incorporated all changes/comments that have been made to it on the list (at least that's what I hope I did...).
Now, this is a first version that we can expand over time. In addition some native speakers or people that are able to write understandable english (so not me) should review the guide once we added it to our cvs.
So, I think we should vote now for the general tendency outlined in the guide and not on every detail. If the guide is accepted, we add it to our CVS, update it, change details that perhaps might not be appropriate/correct and then try to follow it as good as we can.
Here is my +1 (of course) :)
I like it... This is my +1...
But (there's always a but w/ me!) having gotten back to Linux recently, after 3 or 4 years spent on Solaris, I was just thinking about wether a versioning scheme like the Linux kernel could make sense.
For example, if we have to make long-term development (for example the new kernel) which might break a lot of stuff while developing, I was wondering if we should keep "parallel development" up and running. I explain better:
I agree perfectly on the major version, but if we keep (for example) even (0, 2, 4, ...) minor release numbers as "stable" and odd (1, 3, 5, ...) release numbers as "unstable", it might help a lot to keep two trees up and running in development...
Apache HTTPD is (I believe) doing this: 2.0 is "stable", 2.1 is "unstable", and it will be released further down along the platform either as 2.2 (if backwards compatibility can be preserved) or 3.0 (if the new design emerged in 2.1 requires major changes).
For the new kernel it might be very very helpful... We can experiment all together without being worried about putting out an "unstable" release which doesn't guarantee backward compatibility, make proposals, reinvent wheels and rediscover hot water, and then, when we're ready, we can decide how to move forward: incompatible major revision change, or backward compatible minor revision change.
WDYT?
Pier
smime.p7s
Description: S/MIME cryptographic signature
