The case for a kdelibs 4.8

[Albert Astals Cid]

A Dijous, 29 de setembre de 2011, Kevin Kofler vàreu escriure:
> 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).

Please describe the features you need.

> 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.

What you are describing is actually fine means that "old unmaintained" 
libraries are still useful, so I do not see that it helps to prove your point.

> 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