Fwd: KDE Frameworks Release Cycle
kde at kitterman.com
Tue May 20 11:19:59 UTC 2014
On May 20, 2014 4:19:26 AM EDT, Jos Poortvliet <jospoortvliet at gmail.com> wrote:
>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
>> > there's some rule written in stone somewhere which will make the
>> > "everyone will pile up backports only" the new status quo forever,
>> > 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
>cycle with a period of 'bugfixes' that go untested) seems to be that it
>known evil: we're lying about them being stable bugfix releases but the
They are almost completely bugfix. Every now and then something slips through, but those are mistakes.
We (packagers) know exactly how much testing gets done upstream, so we test them before releasing to our users.
No, they aren't perfect, but they are by and large what they claim to be.
>release numbering and lack of new dependencies makes the distro
>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
>while the other releases are minor-numbered (but otherwise
>features as long as new dependencies are optional) means we improve on
>current situation (minor/bugfix releases don't get tested very well)
>also loosing a little (there are new, but optional, dependencies and
>The packagers can simply go to distro management and call this bugfix
>releases, as they will (arguably) be more stable than what they
>accept as 'bugfix releases'. And the developers get what they want,
>So after 5.0, 5.0.1 is released with minor features and bugfixes (but
>mandatory changes in dependencies at all); which continues until
>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.
So your big plan is we intentionally lie about it? I don't think so.
We've pushed nearly every point release to end users throughout the KDE4 cycle. I use them myself. Your characterization of the KDE4 point releases doesn't match my experience.
The first time through on this topic, what fraction of packagers said they saw this new release strategy as an improvement?
On the kde-core-devel version of this discussion it was claimed the goal of the change was to get KF5 fixes out to app developers sooner so they wouldn't work around KF5 issues in their code.
App developers are going to write code that can be deployed. This approach to KF5 releases is, I believe, going to have the opposite effect.
More information about the release-team