The case for a kdelibs 4.8

Scott Kitterman kde at kitterman.com
Fri Sep 30 04:57:53 BST 2011


On Thursday, September 29, 2011 11:47:22 PM Albert Astals Cid wrote:
> A Dijous, 29 de setembre de 2011, Scott Kitterman vàreu escriure:
> > On Thursday, September 29, 2011 08:01:00 PM Kevin Kofler wrote:
> > > On Thursday 29 September 2011, Heinz Wiesinger wrote:
> > > > From what I remember from the desktop summit the picture you
> > > > draw
> > > > here
> > > > is
> > > > quite an exaggeration of what is actually happening.
> > > > 
> > > > kdelibs 4.7 is meant to be frozen for new features, but not for
> > > > bugfixes.
> > > > Bugfix releases of kdelibs-4.7 happenend and I'm sure will
> > > > continue
> > > > on
> > > > happening. As for the versioning I don't see why one of those
> > > > bugfix
> > > > releases couldn't be rebranded as 4.8.0 if that makes things
> > > > easier
> > > > (that
> > > > was even briefly mentioned at the release team BoF). It does not
> > > > solve
> > > > feature backports of course.
> > > 
> > > But one of my points is that we need features too, not just
> > > bugfixes.
> > > Continuing 4.7.x releases solves the problem of bugfixes just fine,
> > > but
> > > entirely fails to address the issue of features.
> > 
> > Even worse, features have already creeped into the 4.7 branch because
> > they are needed and there's no 4.8 branch, so this isn't a theorectical
> > point.
> Why is that bad, that is what was agreed when the freeze took place.

Agreed on by who?   

As a distributor of KDE, we rely (to meet the commitments we make to our 
users) on post-release updates of KDE to be bug fixes and not introduce new 
features.  Once we release, we want consistency with the only change being 
resolution of problems and few/no regressions. 

I don't like the fact that KDE developers decided to ignore their own policy 
on maintenance updates.  I think it breaks your contract with your 
downstreams.  In the case of what's been done so far, it doesn't have an 
impact on us.  The changes were in before our release and are technically low 
risk.  I was aware of it, but becauase of the timing relative to our release 
schedule, didn't object.  That isn't the same as agreeing.

Today was our final freeze for non-critical uploads for our 4.7 based release.  
Elsewhere in this thread there has been discussion about allowing additional 
feature creep into the 4.7 branch because there's no 4.8 branch.  From here on 
out it's a problem for us.

I know most KDE developers don't pay a lot of attention to anything but the 
development release.  For us integrators, it's mostly the one before that 
we're paying attention to, so when you mess with it, we tend to not appreciate 
it.

Scott K




More information about the kde-core-devel mailing list