[Mageia-dev] Release cycles proposals, and discussion

Mon Jun 13 01:56:22 CEST 2011

Hello
+On Sunday 12 June 2011 at 22:46, Michael Scherer wrote :
+> To simplify the discussion, the proposals are all based on the fact that
+> 2 or 3 releases could be supported at a time. We could have different
+> schemes for that ( LTS every X release ( ubuntu ), different level of
+> support ( mandriva )), but as this is a slightly different discussion,
+> let's assume 2 supported releases for now, and let's discuss later for
+> that ( ie next week, once this one is finished )
+> 
+> And roughly, to start the discussion, we have 3 potential releases
+> cycles, based on all inputs we had :
+> 
+> Proposal 1: 
+> 6 months release cycle -> 12 months life cycle
+> ( Fedora, Ubuntu, Mandriva < 2010.1 && Mandriva != 2006.0 )
+> 
+> Proposal 2: 
+> 9 months release cycle -> 18 months life cycle  
+> ( ~ opensuse and the one we used for Mageia 1 )
+> 
+> Proposal 3: 
+> 12 months release cycle -> 24 months life cycle
+> ( Mandriva > 2010.1 )
+
+From a long time mandriva (and now mageia) user POV, for myself I was quite 
+fine with 6 month release cycle, but at work I'd rather not update too 
+frequently and same goes for the rest of the family who generally don't care 
+much for newer versions. And I know that for some people, a big upgrade 
+every 6 month is a lot of work (and skipping a release is more risky).
+
+So I think either proposal #2 or #3 would do, my preference depending on how 
+much could be backported to the latest stable release.
+What I mean is, if it is possible to have backports of newer releases for 
+big projects, like KDE (and other DEs), libreoffice, firefox, samba 
+(important at work), ..., then I am fine with a 1 year release cycle of 
+proposal #3.
+
+If the maintainer of such big projects (especially the DEs) think it would 
+be too hard to backports newer versions to the 8-10 months old stack of the 
+latest stable release (as I have seen recently such discussions on KDE MLs), 
+then I would prefer proposal #2 to not be lacking behind too much.
+
+cheers
+-- 
+Renaud Michel
+