Fwd: Re: Fwd: KDE Frameworks Release Cycle

Raymond Wooninck tittiatcoke at gmail.com
Wed Apr 30 10:04:15 UTC 2014

On Wednesday 30 April 2014 11:28:26 Àlex Fiestas wrote:
> Having a release every month will allow distributions to package fresher
> versions of frameworks since we will virtually remove the synchronization
> problem.
> As an example, Opensuse released 13.1 with KDE 4.8.5 iirc, which already had
> no support from upstream. You had to do that because our 6 months release
> schedule did not synchronize with yours. Having releases every month fixes
> the problem.

Sorry to say, but this is bullshit.  13.1 is the current openSUSE distro and 
was shipped with KDE 4.11.2.  We provided maintenance updates based on 4.11.3, 
4.11.4 and 4.11.5.  At this moment we are even shipping the kde-workspace 
releases as maintenance updates. 

Yes, a distribution release cycle might not match with the KDE upstream 
release cycle, but that NEVER put us in the position to ship an older 
unsupported release.  For every distribution release the openSUSE KDE 
Community team validates both release cycles and then we set a target version 
for KDE.  e.g. for the upcoming openSUSE 13.2, the target is to ship it with 
KDE 4.14 as that this is the latest official release of KDE at the moment of 
the openSUSE release.  Whether this will be 4.14.0, 4.14.1, ...  doesn't make 
that much difference. After the openSUSE 13.2 release we will provide 
maintenance updates based on the 4.14.x releases. 

The issue is that non-rolling distributions sets a stabilisation period before 
the official release. This means that the version that will be shipped needs 
to be in about 2 months before the official release. From that point forward 
only bugfixes are allowed. In the past this was achieved for KDE by making 
sure that at least the Beta version or preferably the RC version of the 
upcoming KDE release was in at that moment. This didn't mean we would ship 
Beta or RC, but we knew from that moment no more new functionality was going 
to be added and therefore we would adhere to the stabilisation period.  This 
will all be gone with the proposed Release Cycle for KF5.  Based on this we 
know already that non-rolling distro's will ship an actually unsupported KF5 
version due to their stabilisation period. For openSUSE this would mean we 
ship an 2 or 3 months old version of KF5 with a lot of back-ported bugfixes. 

So in my book this would make the synchronisation issue bigger and NOT 
virtually remove it. 

> Also ideally, we should break with this tendency of "upstream/downstream"
> and you should become upstream, I would love to see opensuse (and others)
> keeping the release you picked maintained in a branch.
> Even going further, you could (and I think you should) release point
> releases of that Frameworks version.

In other words what you imply here is that KF5 upstream will focus just on the 
master branch and that distributions should setup a maintenance branch and 
maintain that themselves. If this is the goal, then this should be made clear 
from the beginning. In my opinion this would add to the mess as that we would 
end up with a branch per distribution. And what would then be the difference 
by having those patches in our distribution packages ?  I believe distro's are 
already collaborating in a good manor regarding sharing patches, etc. 


More information about the release-team mailing list