The words we use matter, as they often shape not only how one does think about things but also how one can think about the subject. This is because the words we use can lead to excluding some valid options and including invalid ones.
In past releases of the KDE software compilation, right back to when we called it all just "KDE", whenever library development needed to enter a major release cycle (e.g. 2.0, 3.0, 4.0), everything entered that "big change" phase. This included the applications, the desktop, etc. This worked pretty well when the number of applications were low and the overlap between "people who work on kdelibs" and "people who work on applications" was very high. It ceased working so well by the time we started working KDE Platform 4, however.
Application developers either started porting "too" early or "too" late. Some jumped on the 4.x bandwagon quickly and suffered constant API drift, while others waited until "it" (whatever that meant) was stable (whatever that meant). Our users, in the meantime, drummed their fingers waiting for applications and workspace that they could use to be released. The need to get releases of applications out to users put unnecessary pressure on the library development process as well as the workspaces. They were all "welded together" in terms of release management. This reflected how we generally thought of the KDE codebase in general.
At the recent Platform 11 event, we allowed ourselves to really take on the implications of KDE releasing a Platform, Workspaces and Applications as seperate things. It was no longer evident that we had to put application development on pause while library development happened. It was no longer evident that "our" libraries were only for "our" applications.
This in turn allowed us to see our libraries as a collection of powerful, well-integrated, co-supportive frameworks. We started identifying "platformy" bits that had been added over the years and worked on clearly defining what the individual frameworks really are.
The plan that was proposed and accepted at Platform 11 is to start work on the next major version of kdelibs, kde-runtime, kdepimlibs, kdepimlibs-runtime and kdesupport immediately once 4.7 is ready. These modules will be morphed into a clearly defined set of libraries and runtime components with an emphasis on modularity.
We won't be waiting for Qt5, though we will be tracking the development of it closely. When Qt5 is a viable library target then we will change our Qt dependency for Framework development to that. We also are not targeting large new blocks of functionality as we did in the 4.0 release when we took on the major (and necessary) additions of libraries such as Solid and Phonon.
This will allow us to do the Frameworks organization first, influence and participate in Qt5 development as it happens and then take on Qt5 when it becomes ready all in a timely manner. At that point, application developers can begin to decide working on adopting the updated Frameworks as we work on final stabilization.
In the meantime, releases of KDE Workspaces and Applications 4.x will continue on as they have for the last few years: every 6 months. Our work in the Frameworks will not get in the way of those regular releases, preventing application developers from getting stuck between making releases now and jumping into the new versions of the libraries.
For application developers, this means as little disruptive change as possible: the functionality you have come to rely on will remain and in the meantime your releases will go unhindered. Modular libraries means more git repositories, but we will be providing an easy means to "build 'em all at once" just as we do now while allowing for "cherry picking" the specific libraries that you want to use in your application, complete with clarity in dependencies and separate git repositories.
For users, this means you will still get updates to your applications while the Frameworks hacking goes on. No more "great pause" in releases while Qt and KDE library hacking goes on as it did in 2.0, 3.0 and 4.0. It will also allow applications and the workspaces to release once the Frameworks are ready at a pace that allows for great stability and utility on first release.
To coordinate our efforts, the team at Platform 11 came up with solid definitions, detailed listings and clear graphs to guide us. They have been sent for further input on kde-core-devel to include everyone in our community. Branches in the Frameworks modules will start soon (pending 4.7.0) and work will move into full swing. All without nary a ripple in the application development efforts.
This is possible because we have gone from a monolithic mindset, which reflected the successful realities of early KDE releases, to one that reflects the realities of today: we release Frameworks, Workspaces and Applications .. and lots of them. They all rely on each other, work amazingly well together, are derived from the same enormous and vibrant community, but are today much more independent pieces of the whole.
Our ultimate goal is simple: to increase quality as we catapult our libraries into the hands of ever more developers ("Qt-only", mobile, ...) in a timely fashion while minimizing disruptions to our users.
Frameworks, Workspaces and Applications ... Words are, indeed, powerful things.