Stability and Release Cycles - An Idea

[Les Mikesell]

Rahul Sundaram wrote:

>> Yes, you'd have to coordinate this once the RHEL cut happens.  With 
>> the result being something actually useful instead of just another 
>> throwaway beta.   Fedora could just branch their next version at that 
>> point to satisfy people wanting fresh meat every day.
> 
> Explain to me, how that would work. Would Fedora ever move to a new 
> upstream version or stay with the same version that RHEL does? 

The version where the RHEL cut happens would track whatever happens to 
RHEL to the point that the update repos could be repointed to Centos 
when it appears without breakage.  If it doesn't satisfy fedora 
developers to build towards stability even through one version out of 3 
or 4, fedora could just start it's next version early to absorb the new 
untested stuff.

> If it 
> moves to a new upstream version, how would you ensure that RHEL security 
> fixes apply on Fedora? Don't use throw away words and explain it clearly.

People claim to have done upgrades from the earlier corresponding 
fedora->Centos versions, perhaps manually tweaking a dozen or so 
packages so yum could do the rest.  If that can happen without any 
particular planning, I have to think it would be possible to plan it to 
work without tweaking.

>> How is that a particular issue?  Even RHEL jumped FF versions in an 
>> update, so whatever they do should be acceptable in fedora which 
>> doesn't seem to follow any particular policy regarding version stability.
> 
> Firefox was just an example.  If you are not aware of how either side 
> works, no point in discussing a comparison.

Given the FF and OOo jumps in RHEL, I don't think there is a specific 
'how' anymore.  But the point is that whatever RHEL does, I wish the 
fedora release that spawned it would do the same, even if the 
intermediate releases continue to be throwaway betas and even if it 
causes an odd jump in the release timing.  It would have to result in 
less work, less incompatibility, less fragmentation, and more usability 
all the way around.

-- 
    Les Mikesell
     lesmikesell at gmail.com