Proposed adjustments to our release cycles

Matthew Dawson matthew at
Tue Jun 19 01:48:46 BST 2012

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 
> core libraries for a while, but feature upgrades of single applications may 
> 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 

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.


More information about the kde-core-devel mailing list