This Wednesday in KDE land sees the start of the Release Freeze for KDE 4.0, anticipating a final release in December. By then, KDE 4 will have been in development for two years and five months, counting from the aKademy conference in Malaga, Spain, in July 2005.
This freeze is significant for KDE development as evidence of an increasing professionalization in the KDE release process. Where past major releases like KDE 2 (2000) and KDE 3 (2002) involved a relatively close-knit group of insiders releasing a set of source tarballs for Linux distributions to package, the KDE landscape in 2007 is broader and much more diverse. Seventeen modules made up KDE 3.0, and that contained pretty much the entire desktop and all the software that most users would run on it.
During the lifetime of KDE 3, development has become decentralized and some of the most popular applications, such as Amarok, Kopete and KDevelop emerged. They formed their own developer communities who may have little overlap with the core group of KDE library and platform hackers.
In addition, groups of businesses such as the Kolab Konsortium (we kid you not, those Ks are authentic German) have sprung up to serve the needs of companies using KDE. Their ‘Enterprise’ Branch’ flavor of the Kontact PIM suite, featuring additional enterprise features and QA work, is released on its own schedule, independently of the core KDE modules. Completing the scene, a swarm of smaller projects and individual developers take advantage of the KDE libraries, producing thousands of applications, as seen at www.kde-apps.org.
This expansion has caused major changes in the KDE release process. The era of the lone release manager (represented in the past by David Faure and Stephan Kulow) bearing responsibility for getting every module ready just in time for distributions’ release dates has ended, and instead a Release Team representing KDE’s various stakeholders oversees the readiness of all its components.
Also, the release itself has become staggered. To give all the projects and developers who rely on the KDE libraries time to adapt to the changes of a major release, these core libraries and runtime components are being frozen ahead of the rest of the desktop and its applications.
On October 30, the KDE Development Platform version 4.0.0 will be released. This forms a stable set of packages including the libraries, the PIM libraries, and runtime components of the base desktop such as the help browser, IO slaves, and the notification daemon that third party developers require to port their apps to KDE 4. They will be able to download this platform as binary packages for several distributions, easing the porting process.
KDE is expanding the scope of its ambition with this release, by targeting developers of scripting languages as well as its traditional C++ constituency. By shipping bindings for Python and Ruby as part of the Development Platform, the KDE project hopes to signal that these languages are fully accepted for KDE application development. Bindings for C# are due to follow shortly afterwards. And for the first time, KDE will be released for Mac OS X and Windows.
Targeting two new operating systems poses a challenge to the community’s resources. A brief poll of developers showed that although ‘most things work’, the KDE Development Platform version won’t be ready for these platforms at the same time as the Linux flavor. It is hoped that in the long term, this investment will pay off by bringing more participants to Free Software.
The significance of this milestone to KDE fans and users is that the rest of the applications making up the core KDE Desktop are now soft-frozen. While third party developers are just getting to grips with KDE 4, the applications that form the central KDE experience need to get in shape for the KDE 4.0 release. With a lot of issues facing KDE hackers before 4.0 is a usable desktop, all work on new features and UI is stopped, and efforts focus on fixing the inevitable, long list of bugs. A state of the user desktop is the topic of an upcoming article.