- It will be the last feature release in the 4.x series of Plasma Workspaces. Feature development will switch fully to the Qt5 and KDE Frameworks 5 based Plasma Workspaces 2.
- We will be providing stabilization releases (bug fixes, translation improvements, etc.) for two years for the 4.11 release of KDE Plasma Workspaces.
This does not effect, in any way, anything other than the code currently in the kde-workspace repository. Applications are not affected, kdelibs and kderuntime will continue on as they currently are (with kdelibs in a feature freeze of its own already). I fully expect there to be a 4.12 and likely a 4.13 release of the applications, and how long that goes on will be up to the application developers and release team.With that out of the way, some details!
Long Term Release
One of the most exciting things about this direction is that our distribution and packaging partners will be able to have a version that will see releases which focus exclusively on stabilization for at least two years. There will be no new features added after 4.11.0 to Plasma Desktop and Netbook, though the code will be adjusted as needed to maintain and improve existing functionality. This should make Plasma Desktop 4.11 an excellent candidate for inclusion in distributions that have a longer shelf-life.
This is a great opportunity to get changes in that polish things up as they will be available for a long while. Often between releases whole components are revamped and sometimes this results in some polish being lost temporarily. With a long lifespan, these improvements will be allowed to naturally accumulate to the benefit of those using it.
We expect that these ongoing releases to overlap with, and indeed continue after, the initial release of Plasma Workspaces 2.
This was one of the secrets behind the success of KDE 3.5 (back when we called the whole thing "KDE" .. more on that later, though): it had releases for a very long time that focused nearly exclusively on stabilization and polishing. We were working towards the 4.0 release at the time, but it showed that having such a release supported for a longer time can be quite a good thing. We actually did two releases for 3.5.x after 4.0; we even announced our intention to do this when we released 4.0. Unfortunately, the world basically ignored that and one reason might have been because it got buried beneath the excitement around the new major release.
Hopefully by announcing it early and getting the long term release version out well in advance of Plasma Workspaces 2 it will work better and distributions will be able to build plans around it effectively.
Decoupling the Software Compilation (Somewhat)
As KDE's software projects have grown in scope and number, one thing that became increasingly clear is that a single development and release cycle no longer fits all of the projects equally well. Large mature libraries benefit from longer and more conservative cycles while smaller and newer components benefit from rapid iteration. Releasing twice a year may be enough for a desktop shell, but for many applications six months is a larger window than is comfortable. When we add in dependencies between the libraries and the applications, having to time everything just right to take advantage of additions to the libraries becomes increasingly difficult.
This was one of the concerns we took into consideration when repositioning the KDE brand a few years back. We reappropriated the term "KDE" for the community of participants and gave names to each set of software. With KDE Frameworks 5 (the next major release of KDE's core libraries) and Plasma Workspaces 2 both being developed in tandem, we are now free to set each on a release and development schedule that works for them. We won't have to compromise in either direction just to find a single release date that works for both. This also means that application developers won't be hung up waiting for Plasma Workspaces 2, either. They'll have a great 4.11.x workspace to use and develop in and will be able to move to Frameworks 5 independent of where Plasma Workspaces 2 is in its development and release cycle.
I fully expect that we will continue to have coordinated release days for KDE software, and I actually hope that more software will release on those days as we move beyond the strict nature of the "software compilation". However, development cycles will not be the same and some projects will release more often than those couple of times per year. There is a lot of discussion and planning to be done before this is fully implemented and working. This is simply a first small step from the Plasma team towards this.
It's taken a few years to get to this point due to having to wait for the right moments to engage certain aspects of these plans, but it feels very good to approaching the place we envisioned.
Shortening the Wait for Plasma Workspaces 2
Due to all of the above, we will be able to focus our feature development efforts squarely on Plasma Workspaces 2. We will also be able to do releases when it is ready, independent of Frameworks 5. It is not outside the realm of possibility, for instance, to see an initial Plasma Workspaces 2 release on top of a technical preview of Frameworks 5.
By focusing our attention and creating sensible schedules for each component, we will be able to get to Plasma Workspaces 2 as quickly as possible (though no quicker). It also is allowing us to broaden the scope of Plasma Workspaces to bring in a number of "orphaned" modules, such as networkmanager or bluedevil. These components are currently developed in their own repositories and outside the KDE software compilation development cycles. This makes lots of sense for these projects as they can iterate faster and release when necessary more easily. Unfortunately, it makes coordination and integration harder.
With Plasma Workspaces 2 approaching and following it's own rhythm we will be looking to pull more of these projects together. The networking plasmoid, for instance, should not be an add-on developed outside the main workspace efforts, but a properly integrated feature with the ability to participate in the direction setting. So instead of producing a core shell and then waiting for all the pieces to eventually catch up, as we have done in the past, we're working to ensure a complete experience sooner.
How We Arrived At This Decision
We first discussed these ideas among developers who work on Plasma Desktop. We broadened the discussion to the general Plasma developer community, and finally looked for the consensus within those discussions while at the recent Tokamak 6 meeting. We communicated this back to the wider KDE community, first by approaching the release team and ensuring the idea was feasible from their point of view. We then posted an announcement to the kde-core-devel and packagers mailing list with further details. Those discussions have run their course, and so now I'm taking some time to share it with you. :)
The plan has been formulated by consensus (which is not the same an unanimity) and it took quite a while to arrive at as a result. However, it got a lot of great feedback and realistic concerns which has improved the resulting plan in many ways. It's still plastic, however, and we can and will adapt it as necessary as we move forward with its implementation.