The administrators of the KDE Brainstorm forum did not validate this idea, so I am posting it here.

I have tried to find the difference between the release policies adopted by KDE developers for major releases (e.g. 3.5 -> 4.0), major point releases (e.g. 4.3 -> 4.4), and minor point releases (e.g. 4.4.1 -> 4.4.2). The only documentation I have found is a draft of the minor point release policy. At the time of writing, this documentation contains:

"As stable releases these are recommended to a wide user base who expect a high degree of stability. Changes should therefore be verifiable, reliable, regression free [...]."

I guess that the majority of KDE users expects KDE developers to adopt the same criteria in major point releases. However, by looking at what happened lately with the KDE SC 4.4 release, I guess that KDE developers adopt different criteria.

We can consider KAddressBook as a case study. KDE SC 4.4 shipped a new version of KAddressBook rewritten from scratch and based on Akonadi. Unfortunately, the new version introduced several regressions compared to the previous version shipped with KDE SC 4.3. This is reflected by the number of bug reports connected to the new version of KAddressBook:

221915
222677
222678
222690
233078
233093
233095
233097
234080

Indeed, the main author of the new version, Tobias Koenig, wrote on his blog:

"[...] don't expect the current KAddressBook to be as feature rich as its previous version."

Kubuntu 10.4 LTS was released with KDE SC 4.4.2 which contains the new, feature-incomplete version of KAddressBook. Kubuntu packagers neglected to provide the old KAdressBook in Kubuntu 10.4 since it would have been infeasible. Moreover, KDE developers neglect to backport the current trunk of KAddressBook into KDE SC 4.4.3 since minor point releases are not supposed to add features (ironically, the same features that were removed in the KDE SC 4.4.0 release). In this scenario, unless KDE developers change their approach, Kubuntu LTS users will probably be stuck with a feature-incomplete version of KAddressBook until Kubuntu 12.4. I do not find this acceptable, and I do not think that the distributor can be blamed for this problem.

I suggest KDE developers adopt a release policy for major point releases that avoids breaking existing functionality.

I do appreciate the efforts KDE developers are spending to provide this cutting-edge desktop environment. However, the KDE community has seen many users jumping off the train with the questionable KDE SC 4.0 release, and it would be a pity to experience the same once again because of the current release policies.

Best regards,
Alessandro

Totally agree.

Sorry to say, but that's the way KDE goes. Maybe KDE 4.10 will have just one button that does anything you need - or anything the developers think you need

This is a tough one. These new applications are complete rewrites, and I understand that it will take time to reach feature parity with the original versions. However, I agree with the OP that the new version should not replace the old version as the default (or only) app available in KDE SC until the critical core features are all implemented. However even in those cases there will be users who depend on obscure feature X and are now abandoned.

The truth is, I am scared to update KDE SC, as critical apps such as Kaddressbook are loosing core features. I now pour over the changelogs looking not for what has been added, but for what has been removed. That said, I have tested competing apps such as Evolution and found that migrating is not worth the hassle assuming that the KDE-PIM devs are serious about bringing the aps back up to speed quickly. And that does in fact seem to be the case. Tobias is very responsive to bug reports, and even when faced with abuse he often responds in kind.

I should probably finish with this Tom's Hardware quote, in reference to Koffice in their latest Office-App comparison, but relevant for all KDE apps:
"the KDE project tends to make its .0 releases the first look at the development of a new version, not a stable milestone like most other software houses."
http://www.tomshardware.com/reviews/lin ... 565-3.html

Ok, the kaddressbook issue can be considered to be a bad move - not so much because it itself has regressions, but rather that it lacks integration to other kontact apps.

Now, on the other hand, when apps are rewritten from scratch, you can not expect them to have the same features as the old ones did. And there is not enough manpower to maintain the old ones while developing the new.

Gnome, for example, does the same, but in a different manner "in the new release, our default app for this is not app A, but app B which has less features, but is on a right path to become uber-awesome".

BTW, it was possible for Kubuntu to ship the old addressbook.

> BTW, it was possible for Kubuntu to ship the old addressbook.

They refused on the basis that other distros ship with the new Kaddressbook, and the user can make a PPA with the old one if he wants:
https://bugs.launchpad.net/ubuntu/+sour ... bug/507990

From my point of view, things like that are the packager's responsibility*.

"other distros ship ..." is not a real reason, if they (any distro) used this as a guideline, there would be no point in having distros at all.

But, lets not get carried away.

Regressions are bad, very bad, but sometimes necessary

> if they (any distro) used this as a guideline, there would be
> no point in having distros at all.

I wish that you'd say that on the bug! That bug is representative of the general Ubuntu attitude, and especially towards KDE. Having a KDE contributor saying that would provide much-needed fodder for change.


> Regressions are bad, very bad, but sometimes necessary

I agree 100%, but it seems that KDE (as a whole) is a bit too liberal about letting feature-incomplete software out the door.

> wish that you'd say that on the bug! That bug is representative

Once upon a time, I had a chance to /talk/ with Mark - and this was one of the areas mentioned.

Albeit, back then, my position was that Kubuntu is much better than Ubuntu exactly because it receives less attention and is mostly vanilla (it was the time of KDE 3.x when Kubuntu really did a good job of packaging KDE). That's what I call the irony

> I agree 100%, but it seems that KDE (as a whole) is a bit too liberal
> about letting feature-incomplete software out the door.

Yes, I know, one of the things I blame for this is the fact we are now doing a 6-month releases instead of 9 like it used to be. Thus making the development periods (between the freezes) shorter and sometimes there just is no time to finish the stuff you want to.

If we had managed to push all the new things in KDE 4.o, with regressions, it would have been awesome. But some things take a lot more time (PIM, KOffice...) compared to others.

ivan wrote:>If we had managed to push all the new things in KDE 4.o, with regressions, it would have been awesome. But some things take a lot more time (PIM, KOffice...) compared to others.

Shorten release periods is not a bad decision if developers are responsible about their development, known their habilities and don't think that users are just guinea pigs available to play with them.

The first thing you must check before release a new feature to production is functionality because to final users, the most important thing is doing their job without headaches. If I manage my team like Akonadi team I will be fired.

Akonadi was not ready to KDE 4.4, a supposed KDE stable release, so they must wait to a future release. And the funny thing is that with so shorten periods between releases they don't wait so long.

At time of KDE 4.4 release in my home I don't use anymore: Konqueror (blame unstability and past cookies problem), Kontact (blame Akonadi), Kopete (blame Akonadi), Nepomuk (Dolphin crashes and queries still don't works fine), Desktop effects (FullHD videos are slow) and KTTS (I can't use anymore to speak Japanese and Korean so it's useless to me). On the other side I must use Nautilus to fix files with legacy encoding problem (mostly Spanish and Japanese subs compressed files).

Konqueror and Kontact was really painful but, fortunately, now I'm really happy with the alternatives I found.

The final point is that actually I don't know when a KDE 4 stable version will be released. And I'm meaning stable as "KDE 3.5 stable" version and not as "KDE 4.4 stable" version.

Ok, this is becoming yet another boring 'lets **** about everything for the 100th time' discussion.

* ivan out

> Ok, this is becoming yet another boring 'lets **** about
> everything for the 100th time' discussion.

Flamebait, wasn't it obvious? The OP emailed me and asked me to take part in the trolling!

ivan wrote:Ok, this is becoming yet another boring 'lets **** about everything for the 100th time' discussion.

* Ignacio Serantes out

You are probably right and is a lost of time and efforts and don't solve anything. My apologies for my post.

Ignacio Serantes wrote:
At time of KDE 4.4 release in my home I don't use anymore: Konqueror (blame unstability and past cookies problem), Kontact (blame Akonadi), Kopete (blame Akonadi), Nepomuk (Dolphin crashes and queries still don't works fine), Desktop effects (FullHD videos are slow) and KTTS (I can't use anymore to speak Japanese and Korean so it's useless to me). On the other side I must use Nautilus to fix files with legacy encoding problem (mostly Spanish and Japanese subs compressed files).

+1

I would like to make a suggestion which I hope takes up Ivan's point about distributions being free to package the previous version of a newly-coded application. That is to put the the previous fully-functional application in the release alongside the new one.

I fully accept that applications will have to be rewritten from scratch from time to time. Equally it is obvious they will take time to mature. It is also obvious that some users will depend on the full functionality and the usefulness of KDE will be reduced if depended-on features are not dependable.

The answer, surely, is to give users the choice, which in theory they have since this is open-source. But in practice busy users depend on their distributions to provide what they need, and most busy distributions will tend to package what is distributed as source, and not go hunting for alternative applications to package.

So why not provide both versions in the source distribution: the new version for those who want the latest to try out or show off, and the stable production version alongside it for those who need reliability? Then packagers would see straight away two sets of packages to distribute for the application and would tend to pass the choice on to their users.

So, in the case of KAddressbook, could there not be two directories in the source - kaddressbook/ and kaddressbook-stable/, the latter being the old version with only whatever minimal changes are needed to ensure it will still build and run on the new release, while all the development effort went into the new version? That way the new release would have the best of both worlds and everyone would be happy.

I see this as no different from continuing to maintain KDE 3.5 for production use while KDE 4 matured sufficiently to take its place. The same care needs to be taken with applications to ensure the mature code is not just theoretically, but obviously and readily available for a new release, until it's genuinely no longer needed.