FYI. ---------- Forwarded Message ----------
Subject: KDE Frameworks Release Cycle Date: Sunday 27 April 2014, 11:51:01 From: Kevin Ottens <er...@kde.org> To: kde-frameworks-de...@kde.org CC: kde-core-de...@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, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team