Fwd: KDE Frameworks Release Cycle

[Jos Poortvliet]

On Tuesday 20 May 2014 19:07:41 Ben Cooksley wrote:
> On Tue, May 20, 2014 at 6:04 PM, Kevin Ottens <ervin at kde.org> wrote:
<snip>
> > Now, I think we'll have to agree to disagree on something. You believe
> > there's some rule written in stone somewhere which will make the
> > "everyone will pile up backports only" the new status quo forever, I say
> > let's try and find out.
> In the meantime, everyone but the developers will suffer.

Yes, and saying no to every proposal won't change that.

I believe that the only advantage of the current situation (slow release 
cycle with a period of 'bugfixes' that go untested) seems to be that it is a 
known evil: we're lying about them being stable bugfix releases but the 
release numbering and lack of new dependencies makes the distro management 
believe the story.

Perhaps, as proposed, going for a cycle where only the January and July 
releases introduce a major version number and mandatory new dependencies 
while the other releases are minor-numbered (but otherwise unconstrained in 
features as long as new dependencies are optional) means we improve on the 
current situation (minor/bugfix releases don't get tested very well) while 
also loosing a little (there are new, but optional, dependencies and new 
features).

The packagers can simply go to distro management and call this bugfix 
releases, as they will (arguably) be more stable than what they currently 
accept as 'bugfix releases'. And the developers get what they want, too.

So after 5.0, 5.0.1 is released with minor features and bugfixes (but no 
mandatory changes in dependencies at all); which continues until January, 
when 5.1 comes out, with new dependencies and changes.

Consider the potential new API's and components introduced after 5.0 as 
'experimental' until January.