The case for a kdelibs 4.8

[Rolf Eike Beer]

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

Given that it is now proven and tested code, who stops you committing it
into KDE/3.5 branch?

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

The reason to stop master was (as far as I understand) to make the
frameworks branch easily to maintain. If someone is working on 4.8
(bugfixing, features) all this has to be ported to frameworks, too. So you
develop a moving target on a moving target.

Not that I do not understand your point (I'm not sure if I have an opinion
on this yet), just to get a common understanding about the reasons.

I would have wished more than once if we could have done a new release on
an older branch, e.g. a KDE 4.6.6 where the KLineEdits in Konqueror would
be fixed. Some sort of long-term branch, or at least one maintenance
release more when the .0 or .1 is out. You only get severe end user
testing on the new major release when the .0 is out, so those who don't
want to break their system will stay on the older branch, which has bugs
long fixed in the new one. Some sort of chicken and egg problem, of
course, but it would be helpful for those people to get an additional
release with bugfixes after the next .0 is out. This could be e.g. in the
middle between .0 and .1 to not have the release workload for 2 releases
at once. And: yes, I know, this is even more work for the release team.
Poor Dirk.

Eike