Proposed adjustments to our release cycles

[Matthew Dawson]

On June 18, 2012 07:21:29 PM Andreas K. Huettel wrote:
> > > know the current state of the release and commit new features or new
> > > strings when we are frozen, and that's with just one release schedule, i
> > > can imagine the mess with N different release schedules
> > 
> > "Always summer in trunk". As long as releases are not created from the
> > master branch it should be fine. On the other hand nobody should commit
> > without a review anyway, so just commit and push without proper
> > communication with the core developer group is so wrong in the first place
> > 
> 
> That's actually not the whole problem. How will the feature releases of the 
> constantly evolving frameworks interact with the dependency freezes of the 
> applications?! 
> 
> Remember that for distributions it's far better to stick to bugfix releases 
of 
> core libraries for a while, but feature upgrades of single applications may 
be 
> easily doable. 
> 
> Now that means that 
> * either the core libraries plus all the applications will get frozen in a 
> distribution, because newer applications would need newer libraries
> * or we get into branching / #IFDEF madness, because older libraries require 
> other codepathis in applications
> 
> Thoughts?
> 
> Cheers, Andreas
> 
> 

Just looking at Frameworks, its seems there are a few different release that 
happen:

1) Bugfixes.  These are the current 4.8.x release right now.  They strive to fix 
issues without introducing new bugs or features.
2) Major releases.  These are the 4.x releases (which are on pause until 
Frameworks).  These are needed to introduce new features/new API.

It seems, however, that there is one missing we could add:
3) Minor releases - These don't exist, but would introduce support for the new 
technologies replacing old ones.  Things like updating solid, policykit, etc.  
With kdelibs stuck in its current state, these changes don't happen, and we 
end up with distros having to carry patches.

So for Frameworks, how often do we need to have major releases?  If we limit 
bugfixes and minor release to being API/ABI compatible in both directions (like 
the 4.8.x releases should be), but allow for more major changes in a minor 
releases distros have a choice in what version of Frameworks they use.  This 
way fast moving distros (Fedora, Gentoo) can track Minor releases, avoiding 
having to deal with legacy software, while slow moving ones (RHEL, Debian) can 
use bugfixes on a specific minor release to keep up.  We could even try to carry 
one particular minor release while pushing forwards otherwise.

Of course, major release would then we rarer, and we would potentially support 
multiple minor releases at once.  But that shouldn't be too difficult as minor 
releases shouldn't vary as much.

Matthew