cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [vote] Versioning Guide
Date Sat, 24 Apr 2004 15:34:04 GMT
On 22 Apr 2004, at 21:03, Carsten Ziegeler wrote:

> 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.



View raw message