The third bugfix release of the KDE 4.0 series is available. KDE 4.0 is mainly targeted at users who live on the bleeding edge. As a dot-oh release it might have its rough edges. The KDE Community releases a service update for this series once a month to make those bleeding edge users' lives easier. The changelog for KDE 4.0.3 is, although not complete, quite impressive. Especially KHTML and with it the Konqueror webbrowser have seen great improvements in both, stability and performance.

Since KDE 4.0, some Extragear applications form part of the release. Extragear applications can choose to follow their own release cycle, which is what for example Amarok and K3b do. There is also the option to have extragear applications released with KDE. Applications such as RSIBreak (a program to save your health), KGrab (an advanced screenshot-taking tool), KPovModeler (a 3D modelling application). Tom Albers, responsible for the release of the Extragear package says, "The new item in this release is kio_gopher. It's really great that this protocol is still not dead and we now have support for it in KDE4. New technology meets ancient protocol ;-)".

The KDE Team also uses this release to highlight some gems of the KDE package. This time, a closer look is being taken at the KDE Educational software. The KDE Edu project has also recently done some work on their website, which is surely worth a visit. We hope you enjoy this release and notice our commitment to making progress in stability and usability of the KDE 4.0 series while development of KDE 4.1 is going on at more than full speed.

AFAIK, there are also some new features, but as they didn't make it into the changelog, they didn't make it into the announcement. That's why I wrote "not complete" about it. Trying to get everybody to fill the changelog is quite a challenge. *hint*

As in my experience the openSUSE 4.0.x releases had at least as much bugs as the supposedely "unstable" 4.1pre Packages, I happily switched to the more feature-rich 4.1 and never looked back to 4.0.x. If you get bugs as well with 4.0 as 4.1, you might as well learn to cope with 4.1's bugs ;).

While this is basically a good sign for the upcoming KDE4.1, it nevertheless leaves one with a dull taste concerning the release policy which lead to 4.0. Here something went wrong IMHO.

Well, actually my experience has been quite different. While the 4.0.x releases are stable I've already had lots of problems with the 4.1 svn version - both using opensuse 10.3.

Plasma crashing on every startup, lots of apps not even loading - I'm glad I haven't seen that in the 4.0.x versions. :) Anyway, I agree that there are some nifty features waiting for us in current svn. Looking forward to it!

I used to have the stable packages on that machine, then I upgraded to the unstable packages and had these problems. Just deleted .kde4 and checked that there were no more old packages installed. Still some apps don't work (games, amarok). Still nice to see the default settings again in KDE4.

with BIC changes to libplasma happening for 4.1, you have to be really careful to keep your plugins in step with libplasma. that's been the only known source of start up crashes to date. so this is an installation issue, not something in our code.

Absolutely, please can you explain to me, why a distribution can't ship kde 4.1 alpha if it is quite stable, because right now (imho) kde trunk is more stable and has more feature (of course) then branch.

Strange days, the unstable branch is more stable then the stable branch.

I agree. It feels like 4.0.x is a waste of time both for developer and users.

They should keep it as close as possible to KDE 4.1, so stuff get tested and we get a quality release in summer. There is no point in developers wasting time to maintain 4.0.x and backport stuff to it. Nobody uses 4.0 in a production environment and it's not a real stable release. As you say, if users can cope with 4.0, they'll cope with 4.1 alpha and beta.

But the more I think about it, the more truth I see: Nobody wanting to use a stable desktop will use KDE 4.0.x - in this case KDE 3.5.9 is the way to go. KDE 4.0.x is a beta version (there's no flaming here, as that's more or less the official line, can be read in various blogs of developpers).

So basically, we're talking about a work-in-progress, and maintaining a KDE 4.0.x besides developping KDE4 seems as sensible as maintaining an early beta version of a program.

No, even less. The first reduction appeared after installing 4.0.3, killing kwin4.0.2 and starting kwin 4.0.3.

After restarting the session I am at 1500 frames per 5.0 seconds...

wow! this is as fast as my old ATI wothout 3d support! May somebody explain this? Shall I see this as a sign (I will exeggerate) that kwin is making the gpu busy or is it a good sign (in terms that kwin now uses the gpu at all)?

i think (imho) as a user, it is the right decision, i am really concerned about the reaction of users after using kde 4.0.x specially plasma (btw the most important piece in kde), let's wait and see their reaction to fedora 9, ubuntu 8.04-kde4 and in less extend opensuse 11 ( i really hope they postponed their release date and ship kde 4.1 bata )

I tought the contrary.
But as most bugfixes are NOT being ported to 4.0 series, and plasma just crashes everyday for me (on logout and sometimes on login), I just want 4.1 stable and with more features. Having to maintain 4.0 series does not help to improve 4.1, so please, kde tem, do not work on 4.0.4-beta, we want 4.1-stable!

I disagree, please do backport bugfixes! I really don't want to have to backport dozens of bugfixes from 4.1 all alone for Fedora 9's KDE 4.0.4 update which is going to come a few days after the release. Please keep users of the stable branch in mind and backport bugfixes to the stable branch whenever possible. With that logic, i.e. if all the bugfixes go to the unstable trunk only, we'll never have a stable release.

This:
> most bugfixes are NOT being ported to 4.0 series
if it's true (I don't have any metrics to decide either way), is the real problem and should really not happen. But dropping 4.0 entirely is not the solution, actually backporting bugfixes is!

it's a numbers thing: both the number of users as well as the number of different ways the system is used. developers involved with a system tend to use the software in repeated, predictable patterns. introduce new users (even if they are also developers, but of some other software) and issues start to arise pretty naturally / obviously.

that said, i'm happy to see the 4.0.x releases rolling. it's a good practice and the improvements are welcome by many.

counterballancing that, yes, i'm very much of the "concentrate on 4.1 as much as possible (but no more)" opinion as well.

That is because 4.0 is in essence a Beta release. And as a Beta release it is, it doesn't make that much sense for it to have bugfix releases, the best way to make it stable is to continue development towards a Release Candidate state, which is being done in the 4.1 branch.

If you look at Plasma in 4.0 for, which is central to the end user experience, it is far from done, that's why it is allowed to introduce new features in supposedly bugfix releases. Libplasma won't even remain binary compatible until 4.1. All this are characteristics of Beta releases.

Of course 4.1 is more prone to break than 4.0 but, since so many improvements have been done over that old Beta state, it's natural that overall it is better quality.

I know this is beating a dead horse. In any case it is the natural answer for these kind of comments. From the moment that you keep in mind that 4.0 is Beta, lots of strange things suddenly make sense.

Well, if you're building from source, you can patch your Qt, if not, try getting your distro to fix it.
I hope Trolltech will fix it for 4.4, I'm not sure whether they know about it yet though (we just figured out what was wrong a few hours ago, it was filed as KDE bugs in Konqueror and Kopete and not recognized as a Qt bug).

To be fair, a few sites only work with a specific version of the SSL protocol and it was KDE that needed to be fixed. The fix is to try SSL versions in turn (this means 3.1 and then 3.0). I dont't know if the fix has made it into 4.0.x but it is in trunk which will become 4.1.x.

I think you mean 'Looking forward...' :) Made me smile anyway... I was once asked to write an 10,000 word essay on the difference between 'looking and seeing'. If I can spend that long discussing it I think I'll allow you the confusion... ;)

I not entirely sure but I think in this context 'looking' is active but 'seeing' would be considered passive.