KDE Frameworks Release Cycle

[Harald Sitter]

On Mon, May 5, 2014 at 11:11 AM, Martin Klapetek
<martin.klapetek at gmail.com> wrote:
> On Sun, May 4, 2014 at 6:36 PM, David Faure <faure at kde.org> wrote:
>>
>> [Cross posting against my will...]
>>
>> On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote:
>> > I understand that the big concern was about the testing: stable branches
>> > did
>> > not receive the same attention
>>
>> This is not the main concern.
>>
>> My main concern is that application developers prefer to work around bugs
>> in
>> KF5 (previously: kdelibs) rather than fix things at the right level,
>> because
>> "fixes in KF5 will only be available in 6 months, and I want the bug fixed
>> now".
>>
>> Your suggestion (6-months "stable" release) brings us back to exactly
>> that.
>>
>> We'd like to try something better. Monthly small increments.
>> Never "big" changes that break things, they get cut into small increments
>> too.
>> So no reason to buffer changes for 6 months.
>
>
> However this highly depends on the distro policies - if some of the big
> distros say "we will not update KF5 every month because our policies", then
> the 6 months buffer is just moved elsewhere, at the distro level because
> they will update only with the new release. If the application makes a hard
> requirement on some specific version (which would be the point of this),
> then distros would not package that fixed app before there would be that
> particular version of KF5, so I imagine the app developers would still work
> around the bugs in their own code and release a minor version which the
> distro would package. Or worse there would be patches at distro level.

(please also note the relevant thread on the kde-release ML)

You always have an arbitrary delay between when we release something
and when a distro ships it, completely independent of our own cadence.
Currently we may release every 6 months, that does not mean that
distros do, nor does it mean that a distro releases according to our
schedules. For example had Kubuntu stuck to their own feature freeze
then Kubuntu 14.04 would have shipped with KDE Platform and
Applications 4.12 rather than 4.13.

So, a monthly release definitely resolves the presented argument of
people having to do workarounds (well, at least redcues the scope). As
the primary problem is that until a new kdelibs becomes available to
all users of the bigger distributions you have to look at about a
year, dependening on how our 6 month cadance aligns with the
respective distro schedules. So, the distro might be to include $app 3
months after its release, but there is no new kdelibs yet, so $app is
blocked because the next kdelibs release is in another 3 months, at
which point $distro is in feature freeze...

That being said, with a monthly release scheme: if a distro can pick
up a new version of $app they can also pick up a new montly release
for frameworks, and if they can't pick up a new version of $app then
it doesn't matter anyway. So actually dependening on a very specific
and very new version of a framework becomes less of a problem from an
application developer POV; there's at most one month between $app
release and the next frameworks release.

HS