Today, KDE has made available 4.5.3, the November updates to the Plasma workspaces, the applications built on top of KDE's platform, and the platform itself. This release, as all x.y.z updates, contains bugfixes, performance improvements and localization updates only. As such, it's a safe upgrade and recommended for everyone running 4.5.2 or earlier. The update contains a number of fixes in Okular, Dolphin and a series of KDE games. Also, the new shared data cache continues to mature.
The rate of changes in the 4.5 series is slowing down while many developers already prepare for the 4.6 release planned for January 2011, which was soft-frozen only days ago.

Comments

I'm wondering if I missed something on the naming convention. Why is there suddenly a new naming convention: Plasma workspaces plus the Platform. Is that supposed to be the same as the software collection ?

Everyone was starting to get used to SC, I don't think it's a good idea to add new names on top of that, but I might miss the point ?

It hasn't changed, SC was a bit awkward, and wasn't really meant to be used in promo activities, but it's still used when we mean 'Everything that KDE releases at the same time on a 6 month cycle'. The SC was always made up of the three main components, The 'KDE Development Platform' which is kdelibs and so on, the 'Plasma Workspace' which is our desktop offering, and the 'KDE Applications' which are apps that run anywhere, not just on our Workspcae. The only real change recently has been deciding to rename the 'KDE Workspace' as the 'Plasma Workspace'.

Actually the 'desktop' offering is Plasma Desktop. We also have a workspace for netbooks, Plasma Netbook. Other workspaces are in development, including Plasma Mobile and Plasma Media Center. Collectively, they are Plasma workspaces.

The SC still exists for as long as we find it convenient to release a group of stuff together (at the moment, we don't see and end to that). However, the SC excludes a lot of stuff, including digiKam and Amarok and includes stuff you probably don't use or even have installed.

So we're talking more about the stuff that is actual, self-contained blocks, like the (currently two) workspaces, the KDE Platform and the (individual) applications. You need the Platform for any of the others but beyond that you can mix and match - run Gtk apps in Plasma Desktop or KDE apps (whether part of the SC or not) in GNOME, XFCE etc.

And yes, we need to be more consistent, clear and elegant in how we write stuff. Work is ongoing.

We had a 'map' in the original announcement (http://dot.kde.org/2009/11/24/repositioning-kde-brand) however, that could do with a few tweaks - less hierarchy and more things within other things. I was actually working on a new one a couple of days ago. It could fit well in the about KDE page on kde.org

i also counted ~19 fixes (that i could find) to various Plasma components in this release as well. the list didn't make it to the release announcement, unfortunately (my fault for not doing the work, i suppose :).

We've just finished updating the KitchenSync tool last week which is a GUI for OpenSync (currently svn v0.40). I've uplifted the akonadi-sync plugin to work with the current opensync svn code.

There are still some "strange things" to be sourced out.

We expect to have it in official kdepim next, but it will take time, so might be kde4.6 or later will include it as a package or official code.

if you can not wait that long and want to test it for us and help us improve it, then, please, download, compile, install and test. We'll be glad to hear from you. Testing means making backups and not complaining that something is not working as expected.

I just got a new cell phone and was looking for a good sync app, so a working kitchensync would be great indeed.
Maybe I'll try to compile it later today and test it.
What are the requirements? I'm currently running Kubuntu 10.10 - do I need KDE/OpenSync from trunk?

And back to my previous question: Maybe I'll try the KDE PIM beta packages from the kubuntu experimental ppa and try to help with testing.

if one use that workaround thery will proberbly expirience some trouple with tab-ing between windows. I have been talking with some kwin devs on irc and they say that, they would proberbly not re-introduce things needed to use kwin in this kind of settup. Hes advice was to use another window manager than kwin. Just as you know if you ran into same problem as me

JuK is almost unmaintained. Dragon Player is in maintenance mode. Why don't you adopt Bangarang as their replacement for 4.7? This gives us tremendous benefits.

1. It erases magically one of the most hated things to do by KDE developers: replace JuK legacy code with KDE 4 code.
2. Bangarang NEPOMUK usage is exemplary. Bangarang can and should be used to benchmark NEPOMUK, optimize it, and tune it for future use cases (I'm thinking in Amarok ;))
3. Bangarang sorely needs manpower. Maybe if we can divert some manpower from Dragon and put it into Bangarang we could have an amazing media player.
4. The most obvious one is the last. Bangarang is one app. JuK and Dragon Player are two apps. This fact, and the fact that Bangarang makes extensive use of the pillars of KDE, makes this solution a lot easier to maintain in the long run.

Now, how is this related to 4.5.3? Easy: Bangarang HEAD runs beautifully here, in SC 4.5.3, but it has some NEPOMUK hiccups. Maybe if we do this, we can iron those winks and give our KDE desktops a better experience.

EDIT: 3 days after I wrote this, a new update flowed through Git, and I don't have NEPOMUK hiccups anymore!