cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [vote] Versioning Guide
Date Sat, 24 Apr 2004 17:48:24 GMT
Pier Fumagalli wrote: 
> 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).
Ah ok, yes, I think this makes sense. I thought we don't
use versions for this, so we have something like a sandbox
in our repository for such things. But I'm fine with that
as well.

> 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.
Yes, absolutely!


View raw message