The KDE Release Team has decided to release KDE 4.0 this coming January. The release was originally planned for mid-December. The KDE developers want to solve a couple of essential issues before releasing. Having solved some of those issues, among which were glitches in the visual appearance, and in Konqueror, the KDE community hopes to have a KDE 4.0 that will live up to the high expectations for it. Read on for more details.

Meanwhile, the progress towards KDE 4.0 is astonishing. Most parts, such as the KDE Development Platform and a lot of applications are considered stable and well-usable.

Some parts of the desktop experience do not yet meet the KDE community's quality standards and expectations for a stable release. There are also some issues which need to be addressed upstream, for example a bug in certain codecs of xine that cut off audio fragments prematurely. The developers are confident to be able to release a more polished and better working KDE 4.0 desktop in January. The changed plans involve releasing on January 11th, 2008.

At the same time, the release team's call for participation is repeated. To make KDE 4.0 a success, your effort is needed. An overview of current showstoppers can be found on Techbase, KDE's knowledge platform.

This is also a call to the wider Free Software community, and also to companies working with KDE. If you have the resources to contribute, assistance in fixing the remaining bugs is most welcome.

Comments

How does this affect the API/ABI freeze? There are a couple of interesting changes floating around (to KConfig, mainly) that would be beneficial to KDE4, but which are ABI-incompatible, so if they are not added before the freeze, we will have to wait until KDE5.

Is there a list of proposed BIC-changes anywhere and their work/ benefits analysis anywhere? KConfig is pretty core, and I think it would be nice to spend a short time getting it nearer to "perfect" than to spend the next 5+ years using ugly workarounds.

Well QColor handles transparency, so I don't see why making kcolorpicker handling transparency is not possible while keeping API/ABI ? And I also would like to point that API/ABI stability doesn't mean you can't add new function and functionnalities to a class.

The proposed changes were binary incompatible, and KDE is committed to API/ABI compatibility throughout its major versions (this is how the KDE versioning system works). A binary incompatible change thus cannot occur after the API/ABI is frozen (this is certainly frozen at the release of 4.0, and I believe even before 4.0) and before 5.0.

Which changes are in your opinion needed to prevent those ugly workaround? Until now, for the release team, there's no visible reason to break BIC. Actually, no one has pointed out that there's a particular problem, why it would need a BIC exemption. So that's why I said that nothing's planned. Now if someone comes up with a good reason and explanation, we will seriously consider it, but until that does happen, we assume binary and source compatibility.

Well, it's entirely possible that my info is out of date :) It's based on your original delay proposal on the Release Team mailing list.

See if you can find Oswald Buddenhagen (ossi), Thomas Braxton)(?) or Andrea Pakulat (apaku) and ask if there are any BIC KConfig updates that they still want to add. I think ereslibre and dfaure should know about the KJob stuff.

Hopefully, all this has gone in already and I'm worrying needlessly :)

I'm aware of both of these, but it's not clear to me that those are really urgent. And neither David or Oswald did point out that this change is really a good idea to put in, they didn't make clear that it's both necessary changes or punished with 5 years of ugly workarounds.

I assume that all of the above people are aware that they should point it out. So yes, there were possible changes, and it has been brought up within the Release Team, but nobody came up with good reasons to break BIC (yet). If there are those issues, do contact the Release Team and ask for a BIC exemption, however.

Well, I was so looking forward to being able to install KDE4 for Christmas and I thought there would probably be another RC but I really hoped that the release would still have been this year. Anyway, my mind also tells me that this is probably the best solution considering the current state of development.

Well, you can always install an SVN snapshot and follow the progress towards 4.0 in more detail. It's quite well-documented, and I wouldn't consider it hard. You set up the development environment once, then it costs you two commands to get an updated 'latest KDE'. How about that?

It's actually really exciting to observe the progress on KDE 4.0 these days...

I think this is a good thing. The only difference is the release that you will be installing will be the latest RC instead of a final release. The release will be just as stable as it would if they just called it the final release but this is more fitting with the standard versioning scheme. I think any outstanding issues should be fixed before it is considered a final release.

as odd as this may seem, and this surprised me as well, I never really had any problems with Vista. I mean, it is an inferior product in most parameters, such as software installation, management and updates. It's less secure and less stable. a lot of things aren't as well organized as in my distribution and simply don't make sense, and there are regressions from Windows XP. on the other hand, aside from poor design choices, I didn't really encounter any problems. (aside from malware infections, but who counts those nowadays?)

from the article:
"...the KDE community hopes to have a KDE 4.0 that will live up to the high expectations for it." - I assume this is talking more about stability than feature completeness?

If you can't wait, there's ways to try out KDE 4 in its current state right now:
* openSUSE has been preparing KDE Four Live CDs for a while already.
* The Debian KDE team is now offering something similar.
* Fedora Rawhide (i.e. what will become Fedora 9) will include KDE 4 in a few days (the import has already started). There will also be live images, at least for the 3 test releases (alpha, beta, RC), probably also for some inbetween snapshots.
* Then there's the add-on repos for openSUSE, Kubuntu and probably others.
* And finally, you can always build from source, that's what kdesvn-build and the snapshot tarballs are for.

As others have already said, calling the release "4.0 final" sooner is not going to make it any less buggy, so waiting for it to actually be releasable before labeling it that way makes sense entirely. And it wouldn't significantly change your options to get KDE 4 anyway, distros aren't going to ship a version with KDE 4 as default the day KDE 4.0 is released, and I think this slip isn't impacting any distribution's schedule in any significant way (if you're from a distro which is impacted by this, feel free to prove me wrong though).

I was a little disappointed too, i was studying for exams these past two days as was thinking yesterday "kde4 is out" then i saw this today, oh well... as someone stated before its better for them to iron out the kinks and push the release date back rather then release buggy software and meet their deadline (ala microsoft)

"Gut Ding will Weile haben" is a german "Volksweisheit", something like "farmer's wisdom". The german "Ding" means "thing, something, Object" and not what it means in English! The word by word translation would be "Good things need time to maturate/ripen/age".

But I remember an English girl which couldn't drive on german highways without laughing whenever she saw the sign saying "Ausfahrt", which means "exit" in German. Should we better take them down? Now, do you know how the hungarian word for "vegetables" sound to germans ... ?

I think it's a really good decision to delay the release because if the actual desktop (plasma) isn't polished enough the people will say that KDE4 isn't good, even when the underlying libaries and everything else is rock-solid.

I speak Portuguese. I think you'll be happy to hear that the expression "Não coloque a carroça à frente dos bois" does literally mean "Don't place the wagon before the oxen". The portuguese word for "bull" is "touro", not "boi", like the original poster suggested.

This thread makes me smile with all the languages being tossed around. Shows how diverse we as a community are. Even if we do use English as the common tongue, we're here representing many more backgrounds.

You go guys, who cares if it takes longer, I run KDE4 for almost all my critical apps and find it very easy to use, I would prefer a late clean product than a rushed on time one. Keep up the good work guys!!!!