In this release, the KDE team focused on stability and completeness of the Desktop experience. More than 16,000 bugs have been fixed, and many feature requests have been filled. The result for the user is a system that feels faster, takes less time to "think", and works more reliably. The large number of bug fixes goes accompanied with many parts that have got an extra portion of tender loving care. Plasma 4.5.0's new notification system is one example here. It is designed to get less in your way, yet to support your workflow as smoothly as possible. Visually, the striking monochromatic icons make for a more consistent look in the notification area. A highlight of the KDE Applications 4.5.0 is surely Marble, which can now be used for map routing as well as viewing. The Konqueror web browser can now also use the WebKit engine to render its content. The KDE Development Platform 4.5.0 offers a new generic cache for applications that need high-speed access to certain data, such as icons or other pre-rendered artwork. The new KSharedDataCache speeds up loading of many components, while the new HTTP scheduler is optimized for concurrent access to web servers, and makes loading of pages in Konqueror and other parts using the KIO HTTP mechanism faster.

Today's releases are the first in the 4.5 series and will be followed with updated versions approximately monthly that will focus on fixing bugs. The next feature releases are planned for January 2011. If you would like to test-drive 4.5.0, you can do so by installing the packages that should be made available by your operating system vendor. You can also choose to build 4.5.0 from source, the nitty-gritty of that can be found on TechBase. For the impatient, there is also a Live CD available.

Actually, I don't think we'll make 4.5.1 for the Akonadi-based PIM. It all depends on how the beta phase works out. Migrating Kontact to AKonadi is a pretty big step, so we don't want to rush things here.

Kontact 4.4 is still actively maintained and continues to work, so that's what users will use in 4.5. We did not upgrade the version number of KDE PIM, since it's essentially what's in 4.4, anyway.

There will be a beta of Akonadi-PIM in the next days, and from there we'll see how it goes. The PIM team pays special attention to migrating your data, and if the new Kontact doesn't work for you yet, it's easy to switch back as config will be retained for both versions, also cached data (such as disconnected IMAP accounts) can be kept if you're not sure you're ready to switch.

I tried KDE PIM 4.4.92 (Beta 2), and I must notify you that it has, depending on your point of view, finally reached beta quality. It qualifies, indeed, for a Beta 1 moniker, but it needs a lot of testing, because several betas should be done and the whole thing isn't expected to be stable until KDE 4.6.0.

Can you test? I make a pledge to test this, because this is the first of a new wave of features that will surely put the KDE desktop ahead of the curve.

I'm with you. I don't see why there should be any hurry in releasing it as stable. To have it tested by many users the important part is having it packaged, distributed and promoted. Mplayer was being used by tons of people in its Beta and RC days, long before it was promoted to stable. I remember everyone installing a Beta of KDE 2 that came with some SuSE release a long time ago.

So just make it possible to install these Betas along with the latest stable, and get distros to distribute it as an option during the KDE 4.5 life cycle.

I would also become happier if someone ported KNetStats (yes, I know about KNemo, but the former application is more lightweight).

And I expect KDE developers to start working on optimization and solving old bugs (and there are hundreds of them) for KDE 4.6 and onwards. Most of us need a stable and fast DE, not a shiny bug-ridden and prone to crashes one.

Gnome is a whole different matter, they care about compatibility. GTK applications circa 2003 will still be working in year 2010.

But likely not in 2011, or maybe 2012, whenever GTK3 comes out. ;-)

A program like KSensors will likely still just work, so it's totally not a problem using it. If you need support for it which includes development, you're out of luck of course, but saying that if upstream is not working on it anymore make "zero sense to have it installed" seems quite unpractical. Sure, it would be nice to have every single application that ever was available based on KDE3 available in 4, but that's likely not going to happen. There are thousands of other, new applications in its place of course.

Don't get me wrong, I'm sure you've good reasons for stating the above, it just doesn't seem to be the most ingenious reason for not using some piece of software you otherwise really like.

Or maybe you should just install the GTK version of KSensors from 2003 for now. ;-)

That's the point of the first number anyways, for a lot of projects. They only increment the first number to start a whole new series (in our case, the 4.x series). KDE guarantees compatibility between those versions. An application that's compiled for 4.2, will still run when you install kdelibs 4.5.

Same logic applies to GNOME: their 3.x isn't going to be compatible with 2.x

KDE3/qt3 are stable and mature. For stable and mature software maintenance is marginal. So even when they are officially abandonned upstream you can still use and run and fix them, like you can run applications with DOS 5.0 as many in industry do.

Maybe it's because your comment comes over a bit demanding and at the same time narrow-mminded. It sure is easy blame critique you get for your comments on some fanboys, but maybe there's just this tiny little bit of truth in those reactions telling you that your comments are a bit clueless. Just saying, it's not always someone else who's wrong ...

I don't know, but I would guess it's basically the count of all bug reports that have been closed since 4.4.0. That likely includes many duplicates.

Still, it's an awe-inspiring number. Even if many of the bug closings represent relatively little in the way of improvements to the code, try just sitting down and counting to 16,000 some afternoon. I bet it would heighten the appreciation for how much work has gone into this release :-). Go KDE team!!

I also am fine with the idea of KDE-PIM releasing with 4.6. I've always thought it was a bit odd the idea of making a major change at 4.5.1, so in a way I find this more satisfying.

That would be highly misleading and I hope it's not the case. You can close bugs with WONTFIX, INVALID, WORKSFORME, DUPLICATE, etc. Counting all of those as fixed bugs would be pretty ridiculous ... "nah I won't fix this one, there you go one more bug fixed!".

Whatever metric is used in the release announcement, it is wrong. A lot of bugs are never reported, yet fixed. So how do we count those? If we would only count reported bugs which have been fixed by a code commit, yes, the number is smaller. No, it is not more accurate. Many bugs are closed because they have been fixed in the mean time - WORKSFORME is often used there if the developer who fixed the bug never saw the actual bugreport...

So the marketing team simply uses the number of bugs closed in the period between releases. Works fine - you also credit the work of the bug squad with that number. Even on WONTFIX bugs you have to spend time...

On the other hand, they will release beta after beta during the KDE 4.5 cycle (with every minor release, a beta, starting with Beta 2/KDE 4.5.0). And if we don't test these betas, then Akonadi/KDE-PIM release is going to be a flop.

Yes, it includes all bugs that get closed, for all projects that track their bugs on the KDE bug tracker, i.e. it also includes koffice, amarok, digikam, kdevelop, etc.

Still the number is a good indication about how much work the team did, as each of those 16000 bugs is usually closed individually.

On the other side there is the number of bugs opened. It is a good indication about the work YOU did :) And comparing those numbers, you did a better job then the KDE team: Around 16000 bugs closed, around 18000 bugs opened in the last 180 days, so you could say that we have 2000 more bugs :)

You can use bugs.kde.org search service to find how many bugs really got closed as fixed. For example, in the last 180 days around 4600 bugs have been closed as FIXED. Again, this includes all projects. Plasma alone has 700 of those fixes. Additionally, around 600 feature requests have been closed as FIXED (50 in Plasma).

But only mathematicians care about numbers. What really counts is that bugs continue to get reported and continue to get fixed. That's the heartbeat of the KDE project.

Thanks very much to the KDE team for it's time dedication and hard work.
The first thing that I tested was Dolphin, which seems to be good now, stable (after RC3) and fast.
KDE SC 4.5 seems to be quite stable and polish. The only two little problems that I have are the start up time and Bball is still not fixed. Although it's a very responsive Desktop it seems to start up a bit slow. KDE takes longer to start up on my systems than openSuse 11.3 itself.

I wasn't really comparing the login time to that of KDE 4.4. I really meant the general login time of KDE 4. OpenSuse 11.3 takes 30 seconds to reach the login screen on my laptop and KDE 4.5 takes 38 seconds to boot the desktop after that. However, if I log out and then log in again then it takes only 10 seconds. It's only the boot up login that seems to be so slow.