Fwd: KDE Frameworks Release Cycle

[David Faure]

FYI.

----------  Forwarded Message  ----------

Subject: KDE Frameworks Release Cycle
Date: Sunday 27 April 2014, 11:51:01
From: Kevin Ottens <ervin at kde.org>
To: kde-frameworks-devel at kde.org
CC: kde-core-devel at kde.org

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.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-----------------------------------------
-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5