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! Carsten
