The case for a kdelibs 4.8

[Kevin Kofler]

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.

> The KDE Frameworks 5.0 development is not meant to take forever. In fact I
> think it's meant to be finished around early 2012, which would leave us
> with a frozen kdelibs for one KDE SC release, maximum two. It's also not a
> huge *we will break everything! Kittens will die!* release, but basically
> just a restructuration of the code, with little to no adjustments
> necessary for applications. (that was how it was marketed, anyway).
> The way I understood it was that there could very well be a KDE SC 4.9
> release shipping a 4.9 workspace on top of 5.0 frameworks.

I don't think a date of early 2012 is realistic at all. With upstream already 
working on Qt 5, I think it doesn't make any sense whatsoever to break 
everything twice, once for KDE Frameworks 5 and once for Qt 5. Yet I strongly 
doubt that Qt 5 will be out so soon.

Even if the changes required for applications will be small, they will be 
needed (e.g. deprecated stuff will be dropped, and some applications are still 
using it), and I don't think it is friendly to application developers at all 
to have 2 flag days. Plus, it would mean that the KDE Frameworks and Qt major 
versions would get out of sync for the first time in KDE's history.

We should also learn from the past: Things "not meant to take forever" end up 
taking longer than expected anyway, and each time, we're stuck with the 
temporary kludges for much longer than initially planned:
* KDE 4 picked up delay after delay, and the long-lived 3.5 branch ended up 
becoming a mixed feature and bugfix branch (which IMHO is not necessarily a bad 
model, and which could even work for kdelibs 4.7, but it was still an 
exception).
* The Akonadi-based kdepim picked up delay after delay as well, and so first 
its merge was postponed release after release, and only small pieces merged 
each time, and then we got stuck with a long-lived 4.4 branch, including a 
temporary and incomplete Akonadi-based KAddressBook for which we were 
initially promised that it'd be much better in 4.5. And now kdepim 4.4 is 
already discontinued and many users still consider 4.7 too unstable for their 
use.
We must plan for major developments to take longer than the initial optimistic 
estimate.

        Kevin Kofler