The case for a kdelibs 4.8

[Kevin Kofler]

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