From kde-core-devel Thu Sep 29 12:01:50 2011 From: Kevin Kofler Date: Thu, 29 Sep 2011 12:01:50 +0000 To: kde-core-devel Subject: The case for a kdelibs 4.8 Message-Id: <201109291401.51313.kevin.kofler () chello ! at> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=131729774106398 Hi, as you probably already know, a decision was recently made that kdelibs 4.7 would be the last 4.x release series of kdelibs, and work would be ongoing in the 5.0 (frameworks) and 4.7 (KDE/4.7) branches only. I think this is a huge mistake, for several reasons (the "TL/DR" crowd can stop right here, but if you want to know why, please read on!): 1. This puts kdelibs 4 into maintenance mode even before KDE Frameworks 5 is anywhere near a release, let alone versions of the workspace and applications actually using it. As a result, we will fail to deliver new features to our end users for months if not years. And no, kdelibs features do not only target developers: Some application or workspace features require kdelibs changes, or in some cases, even consist of kdelibs changes only, e.g. my Plasma PackageKit integration work is entirely in kdelibs (libplasma). 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. The rule so far has always been that the kdelibs version must be the same as the KDE SC version. Changing this will also break all our Fedora KDE SC specfiles, which all have a: BuildRequires: kdelibs4-devel >= %{version} And what will kde4-config --kdeversion output? The version of kdelibs? Users are going to be confused: "Hey, I installed KDE SC 4.8, why does it say 4.7?" But if you change kde4-config to output some other package's version (which? kde4-config is in kdelibs, so that's the only thing you can rely on being installed at all), you will break Fedora packages even further. (We call kde4-config --kdeversion at build time to enforce that a package must be run against a kdelibs >= the version used to build it, because things like the KDE plugin loader are very strict at enforcing that.) Whatever you do, making the kdelibs version different from the KDE SC version will make kde4-config much less useful. 3. Libraries, due to their nature, have a much longer shelf life than the workspace or applications. In order to keep existing applications working, distributions ship old (sometimes very old) libraries as compatibility libraries. For example, Fedora was probably the first distribution to drop the KDE 3 workspace, but we STILL ship the KDE 3 libraries! And we have no plans to drop them at this time. And RHEL is supporting them until at least 2017 (the scheduled end of life for RHEL 6). Fedora also still ships GTK+ 1. So it is just totally backwards to stop developing the libraries before the workspace and the applications. In fact, it should be just the opposite: We should continue doing kdelibs 4.x releases even after the rest of KDE SC has moved on to 5.x! And bugfix releases alone don't cut it: For consistency between old and new applications, some features should be backported to the compatibility libraries as well. For example, when we switched our default spell checker in Fedora from aspell to hunspell in Fedora 9 (i.e. 4.0 era), I had to add support for hunspell to kdelibs3, or our users would have had to install 2 spell checkers to use KDE apps! (Even several apps in the default KDE installation hadn't been ported to kdelibs4 yet in Fedora 9.) That change never got upstreamed because kdelibs3 is no longer maintained, yet it would have been useful to many distributions. Please keep the life cycle of your software for distributors and end users in mind when you decide your schedules, not just the convenience of a few core developers. 4. The core developers, for whose convenience this change was made, are not the only ones working or willing to work on kdelibs. The main reason that was given for dropping kdelibs 4.8 is that this means one less branch to worry about for the people working on kdelibs, but the people who'd work on 4.8 and 5.0 are NOT the same people! I understand that the developers who are pushing forward towards the new "frameworks" are not interested in 4.8, but you should understand that many other KDE contributors are not interested at all in 5.0 at this time. I, for one, will start caring about 5.0 the day some application (be it a Plasma workspace or a regular application) using it will enter Rawhide (Fedora's trunk), and I guess other distro folks are feeling the same. OTOH, I'm very much interested in working on 4.8, and in fact I already did (see my Plasma PackageKit GSoC work), but my patches are now stuck in reviewboard and cannot be committed due to the deep freeze. Do you really want to encourage wild patching by distributions, adding or backporting a patchwork (pun intended) of features? I remember Aaron Seigo complaining on his blog about the feature backports done by distributions in 4.0, 4.1 and 4.2 era, but if you aren't going to allow any new features upstream, you will be leaving us no choice. 5. We have a master branch which is unused. By convention, the trunk in a revision control system should be where development happens, not branches. This unusual setup is confusing both users and developers, see e.g. http://mail.kde.org/pipermail/kde-windows/2011-September/006070.html So I am urging you to reconsider your decision and reopen master for those people willing to work on 4.8. It's not too late yet, there's a month left until the soft feature freeze for KDE SC 4.8. Kevin Kofler