KDE Frameworks Release Cycle
ervin at kde.org
Sun Apr 27 09:51:01 UTC 2014
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.
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the Kde-frameworks-devel