Release Strategy Proposal

Scott Kitterman kde at kitterman.com
Fri Apr 26 22:15:03 UTC 2013


On Friday, April 26, 2013 03:27:40 PM Sebastian Kügler wrote:
> Hi,
> 
> <tldr>
> Let's make 4.11 the last feature release for platform and workspace in the 4
> series, make 4.11 a long term maintainance release.
> </tldr>
> 
> I would like to propose the following for our release planning in the next
> year:
> 
> - Make 4.11 Platform and Workspaces a long-term maintainance release with
>   bugfix updates for two years
> 
> - After 4.11.0, shift feature development to Frameworks 5 and Plasma
>   Workspaces 2, in order to not delay this forever
> 
> - Applications are not part of this proposal, we'd need feedback from App
>   module maintainers. It doesn't need to be decided along with this proposal
> though. For now, App developers should be encouraged to make releases on
> top of 4.x, and jump onto KF5 "when it's ready"
> 
> Reasons:
> * This strategy will cement our leading role as desktop environment
> * It eases transition to KF5/PW2 by giving ample room to keep the old
> version * It communicates that we do not abandon SC4, but actively support
> it * It makes downstreams happy, particularly those with long term releases
> as they will have a version with multiple years of bug fixes to focus on *
> kdelibs 4.x is already feature frozen, we plan to do the same for Plasma
> after 4.11 and concentrate on PW2 then
> 
> How this will look like exactly:
> 
> 4.11 gets out as normal, but with the clear message: This is going to
> maintained for a longer period of 2 years: If you're doing an Enterprise
> distro, this one is the one you want
> 
> 
> Of course, this being a proposal, its main purpose is to sollicit feedback,
> but I'd also move towards a solution, as far as this describes common ground
> among all stakeholders.
> 
> 
> What do you think?

I have a couple of thoughts for you from a strategy perspective.  My 
impression is that your goal is to get more people working on KFS/PW2 and your 
chosen method to achieve it is by enforcing a stop on feature work in KDE4 
platform/workspace.

Disclaimer: My upstream involvement in KDE development is limited and I only 
know what I read on kde-devel about KFS.

Another approach to accomplishing this goal might be to focus resources on 
making initial releases of some parts of KFS so that external developers can 
use it.  Qt5 code is being written right now and no one outside KDE will be 
looking at unreleased KFS modules to see if using them might make their 
project easier (as an example, Canonical is currently engaged in a complete 
rewrite of Unity using Qt5/QML).  If there are KFS modules that are released 
and available to the broader FOSS community, that ups the chances that people 
might actually make use of them and become engaged in KDE.

The other risk here is that the feature freeze demotivates people and instead 
of working on KFS/PW2, the just stop.  Labor in FOSS projects isn't fungible.

Perhaps, rather than a feature freeze, it would be better to offer more 
encouragement to developers to work on KFS/PW2 (which by the way I think 
releasing some stuff would help) and see how many people are willing to switch 
their focus.  Then reassess based on the work on 4.11 if it's effectively 
frozen itself or if a 4.12 makes sense.

Avoiding a long period of feature freeze between with KDE4 platform/workspace 
development stops and when KFS/PW2 is usable and available is an important 
part of the story.

>From a selfish perspective of my distro, I'd want 4.12 to be the LTS release as 
that lines up with the next Kubuntu LTS release really well.

Scott K


More information about the release-team mailing list