kjpetrie wrote: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.

...

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.

This would be great...if distributions actually behaved this way. But if you look at what actually happened in the case of KDE 4 being released, many distributions switched directly to KDE 4.0 even though they were explicitly and repeatedly told not to. Many distributions seem to want to claim that have the newest bleeding-edge software, whether it actually works or not.

So I think your idea is a good one if so many distributions were not rushing to get the latest software and if they are willing to package two different release versions of major packages, but I think history indicates many, if not most, distributions are willing to do neither.

I agree: the problem is with the distro. Upstream (KDE in this case) write software and the distro - as their name implies - distribute it. Please file bugs with your distros when they package incomplete software.

That said, it would help if KDE releases contained a brief explanation of what is missing in the release notes, and a polite suggestion from the dev that the particular application not be pushed to end users. I know that they did do this for KDE 4.0 but it was ignored, yet, I think the distros are more jaded now. Just a general statement, such as "Kaddressbook is feature incomplete and not ready for end users", would help us file bugs and get the software repackaged.

Totally disagreed.

Just take a look at the KDE komepage: it says "KDE SC 4.4 (recommended for end users)" - that's not a warning "you get an incomplete beta". And if you look at the "KDE 4.4.2 Info Page" the only mentioned bug is "KDE Security Advisory: KDM Local Privilege Escalation Vulnerability"

That's not a way to say "hey, this is beta"! It's a call for trouble.

* ivan back for now

@kjpetrie

I mostly agree with you, with a note that in the versioning system, we have tags for every KDE release, so there is no really need for kaddbook and kaddbook-stable.

@dotancohen

"That said, it would help if KDE releases contained a brief explanation of what is missing in the release notes, and a polite suggestion from the dev that the particular application not be pushed to end users."

This is a very good proposal, and we have a mailing list that is supposed to be read by the packagers. I have no idea whether PIM devs posted anything about kaddbook but they really could have.

Naturally, even then, there would be problems - packagers sometimes ignore the mails on that list (I had a first-hand experience ).

@samhain

4.4 /is/ stable, and is not an 'incomplete beta' as you've put it. The problem is not stability, but rather replacing one application with another one that it not as mature (and that bears the same name).

When comparing KDE3.5.10 to KDE 4.4.2 then 4.4.2 is from the users point of view exactly what you say: "replacing one application with another one that it not as mature"

ivan wrote: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.

I understand that a new application that is rewritten from scratch may not have the same features as the old one did and I understand that there is not enough man power to maintain old and new versions concurrently. But that is not the problem.

What I suggested in my first post is that KDE developers release a new application in a major point release only when it has reached feature parity with the old one. The old version of KAddressBook shipped with KDE SC 4.3 worked just fine and I guess it did not need maintenance. The new version of KAddressBook could have easily been shipped with KDE SC 4.5, together with the new version of other KDE PIM applications. On the contrary, the new, feature incomplete version of KAddressBook (which is not recommended for end users) was shipped with KDE SC 4.4 (which is recommended for end users).

ivan wrote: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".

If Gnome ships A until B has reached feature parity with A, this release policy seems to me more reasonable than the one of KDE.

Best regards.

TheBlackCat wrote:But if you look at what actually happened in the case of KDE 4 being released, many distributions switched directly to KDE 4.0 even though they were explicitly and repeatedly told not to.

I guess that the big misunderstanding between KDE developers and packagers was caused by the versioning scheme adopted by KDE developers. To the best of my knowledge KDE is the only project where ".0" versions denote a release aimed only at developers, testers and early adopters. The same is denoted by "beta" versions in the majority of the projects I have worked with. A packager would have probably been more comfortable with a versioning scheme as follows:

KDE SC 4.0 -> KDE SC 4.0 beta
KDE SC 4.1 -> KDE SC 4.0
KDE SC 4.2 -> KDE SC 4.1
KDE SC 4.3 -> KDE SC 4.2
KDE SC 4.4 -> KDE SC 4.3 (with KAddressBook 4.3 beta?)

Best regards.

alessandro.rossini wrote:What I suggested in my first post is that KDE developers release a new application in a major point release only when it has reached feature parity with the old one.

I agree with a small addition 'feature-parity not counting wanted regressions, if any'.

But when we do make a mistake (maybe even intentionally) distributions should fix it.

alessandro.rossini wrote:If Gnome ships A until B has reached feature parity with A...

No, they ship B by default (and that's what counts, to be honest) - example Empathy vs Pidgin.

alessandro.rossini wrote:To the best of my knowledge KDE is the only project where ".0"

Please, lets not start with 4.0 again

Agreed. The "4.0 was not ready" mantra is more than old, it is rotten. Many years have passed since then. Let's focus on what KDE is now, rather than what it was.

einar wrote:Agreed. The "4.0 was not ready" mantra is more than old, it is rotten. Many years have passed since then. Let's focus on what KDE is now, rather than what it was.

In my opinion, the "x.0 was not ready" mantra is not rotten at all. KOffice 2.0 was not ready, but it was a major release aimed at developers, testers and early adopters. KAddreeBook 4.4.0 was not ready, but it was shipped as part of the KDE SC 4.4.0 major point release aimed at end users. The former scenario is, to a certain extent, acceptable. On the contrary, in my opinion again, the latter scenario is not reasonable; not even if KDE developers recommended packagers to package everything of KDE SC 4.4.0 but KAddressBook. Therefore I suggested KDE developers to avoid using the same release policy for major releases and major point releases.

As far as I understood, KDE SC 4.5.0 will ship the new KMail 2.0 that is based on Akonadi. If KMail 2.0 will not be ready but will replace the current KMail anyway, I will be forced to reconsider my default PIM suite.

By the way, is there anywhere I can find a discussion about the advantages of using version "x.0" instead of "beta" to denote a release aimed at developers, testers and early adopters?

Best regards.

I was able to compile 4.4.2 with the stable address book from 4.3.5. I hope that the KDE team can use this to revert the address book until Akonadi is stable and feature-complete.

Instructions for compiling this version are here:

https://bugs.kde.org/show_bug.cgi?id=233078

Best Regards,
Kumaran

@kumaran

Akonadi is stable and feature complete - applications are the ones that are not fully ported to it.

As for reverting, don't expect it to happen (esp when a lot of missing things got implemented since 4.4) - I can't talk for PIM developers, but I don't think anyone would be willing to revert stuff that has been developed.

kumaran wrote:I was able to compile 4.4.2 with the stable address book from 4.3.5. I hope that the KDE team can use this to revert the address book until Akonadi is stable and feature-complete.

I do not think this is feasible. However, Tobias Koenig has already fixed many of the bugs of KAddressBook. A reasonable compromise would be that KDE PIM developers accept to backport the current trunk of KAddressBook into KDE SC 4.4.3. Unfortunately, as discussed in bug 233078, some of the KDE PIM developers are against this solution.

Best regards.

@ivan

Akonadi has been claimed to be feature complete and stable for some time now. Unfortunately, I have a hard time believing this to be true. The feature complete claim may be reasonable, but it is hardly stable. I have many instances where Akonadi will simply fail to start, causing Kontact to fail during start with no feedback. The Akonadi console does not reliably manage resources, with intermittent hangs for indeterminate periods. The debugging is sparse at best, making it very difficult to pinpoint problems.

From a software architecture perspective, the Akonadi system is unnecessarily heavyweight. I am not convinced that a MySQL server is required to hold the PIM data. Most users simply want to keep a single address book and calendar. Connections are brokered by the Akonadi daemon anyway, so there is no reason to introduce yet another point of failure. Indeed, there was a bug recently that was caused by a de-synchronized version of MySQL. SQLite would have been more than sufficient for this purpose.

You cannot know if Akonadi is stable until enough users have hammered on it. There will be many bugs that the developers can't readily reproduce (i.e. NFS with Kerberos, losing its connection to home directory in the middle of the night). It is dangerous to force users who are expecting a stable release to deal with alpha-quality software. Maybe an even/odd release convention should be considered in which users know exactly what they are getting before they upgrade.

Our users are business users who have no interest in troubleshooting problems with their contacts and calendars. Therefore, I had no choice but to revert the address book to 4.3 locally. Similarly, when developing the CalDAV resource connector, I had no choice but to use the stable KResource system, even as a number of people were suggesting to place my bets on Akonadi. The result is that the CalDAV connector works nicely while Akonadi is still not integrated into Korganizer.

It is disappointing that the KDE team is not able to put themselves in their users' shoes and predict the downstream problems that these hasty decisions cause. As much as the open source community would like to believe themselves to be technically superior to commercial software vendors, it is decisions like this which encourage business users to stop using open source products. I have been a user of KDE since nearly its inception, and would really like to see the polish that once defined KDE against competing desktop environments.

Best Regards,
Kumaran

alessandro.rossini wrote:A reasonable compromise would be that KDE PIM developers accept to backport the current trunk of KAddressBook into KDE SC 4.4.3. Unfortunately, as discussed in bug 233078, some of the KDE PIM developers are against this solution.

That is against KDE policy. Features cannot be added during a x.x.x release, only during an x.x release. Similarly, backwards-incompatible API changes cannot be changed during a x.x release, only an x release.