The case for a kdelibs 4.8

[Kevin Kofler]

Rolf Eike Beer wrote:

(re the support for spellchecking with hunspell)
> Given that it is now proven and tested code, who stops you committing it
> into KDE/3.5 branch?

What for? There are no plans to do a 3.5.11 or 3.6.0 release, ever, and the 
one major distribution known to sometimes ship release branch snapshots from 
after the last release of the branch (Debian) just dropped the KDE 3 libs 
from their distribution (a decision I also don't agree with, FWIW, but 
that's off topic here). In addition, that patch is not exactly a bugfix…

The 2 patches against 3.5.10 (one for KSpell and one for KSpell2) can be 
found in Fedora dist-git, and also in KDE Bugzilla. If you think they should 
be in the 3.5 branch, feel free to commit them. But AFAIK, we aren't really 
expected to commit anything to the 3.5 branch anymore, even though AFAIK 
there's no official freeze like the one being enforced on master.

By the way, I also have a patch for K3Spell in the KDE 4 libs. We also ship 
that patch in Fedora. It's basically the same as the KSpell patch for the 
KDE 3 libs, and attached to the same bugs.kde.org report. But I don't know 
whether anything actually still uses K3Spell. (The reason I didn't commit 
that was because the Sonnet maintainer wasn't happy with the idea of adding 
a new feature to that compatibility API, even though it's needed for 
integration. And of course now I couldn't commit it anymore even if I wanted 
because kdelibs master is frozen, which brings us back to the topic…)

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

You'd just have to do regular merges from master instead of regular merges 
from KDE/4.7. It wouldn't change much apart from being more consistent with 
common best practices for SCM use.

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

That also makes a lot of sense (so +1 to this suggestion), but it is a 
different issue from the one at hand.

        Kevin Kofler