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