KDE Frameworks Release Cycle

Hello people,

As you may have noticed, we're covering quite a few tasks here during the
sprint. But, we're also having discussion topics, and the most important one
we covered is the release cycle. Indeed, we got the question several times
already of "once 5.0 is out what will happen?" It is what I'll try to address
in this email.

Short story: we'll go for a one month release cycle, with no branch.

You can stop reading here, thank you, bye!


Still here? Oh you want more details!? OK, read on. :-)

So, we had a team discussion here with Albert, Aleix, Alex, Alex, Aurélien,
David, Rohan and myself. We juggled with several options, trying to address
the following constraints:
* We don't have many contributors;
* We don't have enough testing in the stable branches, developers tend to
have a hard time to dog food those;
* We don't have enough contributions coming from the application developers
because it takes a lot of time for them to benefit from their changes so they
tend to workaround instead and consider kdelibs more and more as a black box;
going forward we don't want that for KDE Frameworks.

We ended up settling on the "one month cycle, no branch" option because we
think it should address the constraints above. In a more detailed way here is
what we mean by "one month cycle, no branch":
* Everything is developed in master, so each release will contain a few new
features and bugfixes;
* The only freeze will be a message and docbook freeze, it will happen for
the last two weeks prior to release (so we'll be in message/docbook freeze 50%
of the time);
* Releases will materialize in the form of a tag and a tarball;
* We tag the release at the beginning of each month, as close as possible to
the first day of that month;
* Unlike previously, tags will be pushed immediately, we'll first tag a rc1
and produce the tarballs, if no issue is found by packagers in a week then it
will be retagged as final, if issues are found we'll tag a rc2, etc.

Currently David will be the one producing the releases. He'll announce the
exact dates for the freeze and release of the current cycle during the first
10 days of the cycle since that's partly based on his own availability.

Of course, going with this type of cycle comes with some price of its own:
* Features in released modules can only be introduced in a very fine grained
way so as to not jeopardize the stability;
* CI should be always green, breakages should be treated as stop the line
events (all commits following a breakage should only be to try to get things
back to normal);
* There should be a strong focus on automated tests and peer review: all
modified code should come with corresponding tests; if you got a framework
which is low on test coverage because of its architecture it's likely time to
focus on the tooling and test harnessing.

Thanks for your attention.



Re: KDE Frameworks Release Cycle

By Luigi Toscano at 05/04/2014 - 09:27

Kevin Ottens ha scritto:

So, I've seen no discussion about this (not on this list, I think it's going
on somewhere else) but I would like to rise my concerns with this decision.

It can increase the "balkanization" of the version shipped by distribution.
This is going in the opposite direction of the advocated "give users a real
KDE experience". With no stable branches, distributions will have to randomly
choose one branch to stabilize and the risk is that based on their schedule,
they will choose different versions, heavily patching them (_more_ than what
happens today, where there are few synchronization points).

Other big projects with frequent releases, like the Linux kernel or Firefox
have stable branches too; not all of the releases, but some of them. Firefox
had to provide a "esr" version (long support, one year) because it's not
really possible to update an entire stack in long-term supported
distributions. And Firefox is mostly a leaf in the dependency tree (with the
exception of libnss and libnspr, which can break and broke in the past from
one esr to another); here we have an entire bunch of "core" libraries (as in
Linux with its long-term branches).

I understand that the big concern was about the testing: stable branches did
not receive the same attention, but I think that killing them is not the
solution; solutions include an increase number of automated tests (unit,
integration, scenario) as first step, and a bit of time invested in the rest
(manual) testing, with contribution of distributions but not only them.
We had a lot of coding sprint, we can organize test sprints as well (which
benefits also the main master branch, of course!)

I also think that many frameworks will stabilize after the initial rush, so it
will. I suspect (just a feeling, not backed by any fact) that Tier1 will
stabilize sooner, Tier3 will have more moving part (please note that this is
not about ABI/API, which I'm sure will keep the compatibility as it was
before). If this is true, it could help in creating "naturally" stable
branches; KDocTools is a good example, it's unlikely to have new important
changes too frequently, but I guess it will be the same for KI18n and others.

Minor point: the original statement of "three releases" for Porting Aids
should be fixed to be time based (I guess at least 6 is not 9 months).

So, my proposal(s).
I think that some kind of long term branch branch is needed. It could be an
yearly release (and we could do a testing sprint for that, solving the problem
for the "love"), or a bit more frequent, like twice a year (no more!); still
at least one release could benefit from a sprint. Collaboration from
distribution is needed, so that they can coordinate. In case of yearly
releases, if few distributions want to have an official stabilization branch
(like in Linux) they will able to create and manage a special branch (with
some input from developers).
After the initial rush, revise the release schedule in the light of the
"stable" frameworks, maybe they can be "naturally" on a stable branch (because
no big changes will land in them).
Possibility for opting out from the monthly releases for individual frameworks
(i.e. still released with the bundle, but no monthly changes). I'm wondering
about going this way on KDocTools.


Re: KDE Frameworks Release Cycle

By Ingo =?iso-8859... at 05/08/2014 - 16:59

[This message is a reply to all people requesting a long-term-maintained
frameworks branch.]

On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote:
In case of the Linux kernel those stable branches are maintained by
dedicated volunteers. Without those volunteers there wouldn't be any
long-term-maintained Linux kernel branches.

If you (Luigi and/or Alex [Neundorf] and/or Patrick) are willing to
maintain a stable frameworks branch then nobody will stop you from doing
so. On the contrary, I'm sure many people would be grateful for your
initiative and all the work you put into maintaining such a branch. But
please don't expect other people (in particular the small number of
frameworks maintainers) to do this job for you.

Remember, that in KDE (as in any other volunteer organization) you
should never say "we should do foo" unless you mean "I volunteer to
[help with] do[ing] foo".


Re: KDE Frameworks Release Cycle

By Alexander Neundorf at 05/05/2014 - 14:54

On Sunday, May 04, 2014 16:27:44 Luigi Toscano wrote:
Maybe this should be considered seriously ?
If we have more than 50 libraries, do all of them need a full new release
every month ?
As Luigi says, some of the smaller libraries may not see many changes at all,
and maybe only "old style" patch level releases for them would be good enough


Re: KDE Frameworks Release Cycle

By David Faure at 05/04/2014 - 11:36

[Cross posting against my will...]

On Sunday 04 May 2014 16:27:44 Luigi Toscano wrote:
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

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.

Re: KDE Frameworks Release Cycle

By Patrick Spendrin at 05/08/2014 - 16:13

Am 04.05.2014 18:36, schrieb David Faure:
One thing I want to mention here because I think there is no real work
When will you add new dependencies?
In a rolling release process this is possible every month. From a
packagers point of view, this is hardly doable:
You cannot accept new dependencies in a security update.
So what is the solution for the packager?
Probably make a branch on top of the release that was used first, and
try to find as many bug fixes as possible that will still apply.

While rereading your email I see the following thing:
"fixes in KF5 will only be available in 6 months, and I want the bug
fixed now".
If these are _fixes_, why are they not backported to the stable branch

Maybe we should fix another issue here, and instead modify our
understanding of stable branch. Even if it is hard for me, the
maintainance of the Linux Kernel could be an example: with clear
maintainers (or teams) of branches which will check which issues need
backports. I think this is also the way it would happen (distros would
probably try to maintain stable branches together), so I'd prefer if
we could plan this ahead of the first release instead and possibly
involving the developers of the libraries.


Re: KDE Frameworks Release Cycle

By Joseph Crowell at 05/04/2014 - 17:19

0.0.1 version releases seem to work pretty well for Qt and are released
as necessary iiuc.

On 5/5/2014 2:36 AM, David Faure wrote:

Re: KDE Frameworks Release Cycle

By Martin Klapetek at 05/05/2014 - 04:11

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.

Imho distributions' opinion should be highly taken into consideration
because these are the people actually delivering our code to 98% of users.

I like the original proposal, but I also think we need to stay pragmatic
and work with real world facts.


Re: KDE Frameworks Release Cycle

By Sebastian =?utf... at 05/07/2014 - 09:22

On Monday, May 05, 2014 11:11:53 Martin Klapetek wrote:
Worse, they'll stack up: Wait for new kdelibs first (could take up to 7
months, including freezes, and only then the distro freeze period (imagine the
target kdelibs release is just past the distro freeze deadline). You'll easily
end up with "this bug will be fixed in one year".

Re: KDE Frameworks Release Cycle

By Harald Sitter at 05/05/2014 - 05:03

On Mon, May 5, 2014 at 11:11 AM, Martin Klapetek
<martin. ... at gmail dot com> wrote:
(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.


Re: KDE Frameworks Release Cycle

By Marco Martin at 04/28/2014 - 06:18

On Sunday 27 April 2014, Kevin Ottens wrote:
on one hand I'll probably miss feature branches, on the other hand, I really
like the discipline that this methos requires, it may well drive to a good
quality increase