Fwd: KDE Frameworks Release Cycle

Scott Kitterman kde at kitterman.com
Tue May 20 13:45:36 UTC 2014

On May 20, 2014 8:52:30 AM EDT, Mario Fux <kde-ml at unormal.org> wrote:
>Am Dienstag, 20. Mai 2014, 14.09:18 schrieb Scott Kitterman:
>Morning Scott
>> On Tuesday, May 20, 2014 14:07:02 Kevin Ottens wrote:
>> > On Tuesday 20 May 2014 07:55:26 Scott Kitterman wrote:
>> > > I'm open to discussing change, but so far the change is "You're
>on your
>> > > own, get over  it".  Not a lot to discuss in that.
>> > 
>> > It's not at all the way it's been thought, it is unfortunate if it
>> > perceived that way. Looks like I can't frame and present it
>> > then.
>> > 
>> > Really the intent is to try something different to foster higher
>> > output and from there move toward fixing the pain points it might
>> I get that.  The problem is the new thing won't be useful to us.
>Ok, fair enough. So what would be your proposal to make it better?
>Thanks a lot for a constructive discussion (and that's not ironic!)

This or something very like it was already suggested by someone else, so I'm not claiming this as my idea, but I think a reasonable compromise would be something like:

 - Monthly feature releases as proposed.

 - Select one release every 6 months as long term support (I'd suggest March/September) which has a stable branch.

 - Developers backport "safe" fixes to the stable branch.

 - For complex changes the can't safely be applied to the stable branch, a new branch off of stable is created and the developer issues a call for testing (maybe on this list).  If testing succeeds, it gets merged back to stable.

 - Updates to the stable branch get released monthly at the same time as the monthly feature release.

Something like that. 

Scott K

More information about the release-team mailing list