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