Fwd: KDE Frameworks Release Cycle
jospoortvliet at gmail.com
Tue May 20 08:19:26 UTC 2014
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:
> > 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
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.
More information about the release-team