Fwd: KDE Frameworks Release Cycle

[Scott Kitterman]

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
>is
>> > perceived that way. Looks like I can't frame and present it
>properly
>> > then.
>> > 
>> > Really the intent is to try something different to foster higher
>quality
>> > output and from there move toward fixing the pain points it might
>create.
>> 
>> 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