The case for a kdelibs 4.8

[Kevin Kofler]

Scott Kitterman wrote:
> We did this in Kubuntu and it was confusing.  It was also technically
> challenging.  Speaking as someone investing a lot of time in trying to do
> a high quality job of distributing KDE to end users: Please.  Never, ever,
> do this to us again.

+1

> The transition from kdepim 4.4 -> 4.6/4.7 was a special case.  I hope it
> stays that way.  While there wasn't another way to do what had to be done
> in that case

Actually, there would have been another way: revert the Akonadi merge by 
copying the 4.4 branch of kdepim to 4.5 and release that as kdepim 4.5. As I 
wrote in the other mail, that would also have allowed updating KAddressBook 
(which was already Akonadi-based in 4.4) to the much improved version from 
the 4.5 branch (while discarding all the other, unstable changes from 4.5). 
And it would have prevented the version number confusion, the chaos with 
translations etc.

But IMHO the best solution would have been to postpone all this Akonadi 
stuff to 5.0 right from the start (especially considering that 5.0 is 
seriously being worked on now, to the point of stopping kdelibs 4.x 
releases). The original plan was for 4.0, that train was missed. 4.5/4.6/4.7 
is way too late in the 4.x cycle for that kind of major change, it belongs 
into a major release.

We (the KDE community) are now in the paradoxical situation where we won't 
ship even small uninvasive features in kdelibs, yet we happily replaced the 
PIM apps, which handle data many users consider essential, with what was 
essentially a rewrite. Yet both those apparently contradictory decisions are 
symptoms of the same problem: We really need to get used to working with 3 
branches: next major feature release, next minor feature release and bugfix 
release. It is needed in some cases. It would have been needed for kdepim 
(next major feature release = KMail 2 etc. for 5.0, next minor feature 
release = small, incremental improvements for 4.n+1) and it's needed now for 
kdelibs. Each time we try to save a branch, the conflicting requirements of 
doing long-term refactoring vs. delivering new features to our users lead us 
straight to a disaster.

> it should not server as a general success story others should model
> themselves after.

Big +1 to that!

        Kevin Kofler