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