MRE for KDE Frameworks

Scott Kitterman ubuntu at kitterman.com
Tue Dec 2 00:58:34 UTC 2014


On Monday, December 01, 2014 04:32:25 PM Kees Cook wrote:
> On Fri, Nov 28, 2014 at 02:33:00PM +0100, Jonathan Riddell wrote:
> > Hola Tech Board, I'd like to ask for a Micro Release Exception for KDE
> > Frameworks, or depending on how you look at it extending the KDE Micro
> > Release Exception to KDE Frameworks.
> > 
> > KDE Frameworks is the new name for kdelibs which was previously released
> > with KDE SC.and we're done MRE updates for some years.
> > 
> > The KDE Frameworks developer have said they don't have the manpower to
> > make
> > bugfix releases and instead are making monthly releases with both bigfixes
> > and new features.  There will be the same assurances of stable ABI, API
> > and
> > no new features coming from those ABIs.  So any applications using these
> > libraries will not be using any new features but will be using the
> > bugfixes.
> > 
> > Allowing the MRE will allow us to get bugfixes out to users, it'll also
> > have the nice affect that developers wanting to use KDE Frameworks will
> > have new versions available.
> 
> This seems entirely reasonable to me. Almost seems like we should add
> something to the MRE policy that says something like "MREs will track
> package names if a package is moved". If this is truly just kdelibs
> renamed, I see no problem at all. :)

It's not.  The code is the same, but the maintenance philosophy is different.

In kdelibs, it was bugfix only in micro-releases (and very consistent with our 
SRU policy).

For KF5, it's different.  There are no micro-releases (as a rule).  There are 
only regular minor releases which include both new features and bug fixes.  The 
new features are supposed to be isolated in new classes (AIUI) so that 
existing API/ABI remains stable.

This is different than we normally do and it does not have a long track record 
yet.  In theory, it might be OK, but in practice, I'm glad I don't have to 
decide.

Scott K



More information about the technical-board mailing list