From kde-frameworks-devel Sun Apr 27 09:51:01 2014 From: Kevin Ottens Date: Sun, 27 Apr 2014 09:51:01 +0000 To: kde-frameworks-devel Subject: KDE Frameworks Release Cycle Message-Id: <20570335.tvCvlO2tje () wintermute> X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=139859230601141 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============7240117970650530650==" --===============7240117970650530650== Content-Type: multipart/signed; boundary="nextPart3232807.kIJa1ZbUJK"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart3232807.kIJa1ZbUJK Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Hello people, As you may have noticed, we're covering quite a few tasks here during t= he=20 sprint. But, we're also having discussion topics, and the most importan= t one=20 we covered is the release cycle. Indeed, we got the question several ti= mes=20 already of "once 5.0 is out what will happen?" It is what I'll try to a= ddress=20 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=E9= lien,=20 David, Rohan and myself. We juggled with several options, trying to add= ress=20 the following constraints: * We don't have many contributors; * We don't have enough testing in the stable branches, developers tend= to=20 have a hard time to dog food those; * We don't have enough contributions coming from the application devel= opers=20 because it takes a lot of time for them to benefit from their changes s= o they=20 tend to workaround instead and consider kdelibs more and more as a blac= k box;=20 going forward we don't want that for KDE Frameworks. We ended up settling on the "one month cycle, no branch" option because= we=20 think it should address the constraints above. In a more detailed way h= ere is=20 what we mean by "one month cycle, no branch": * Everything is developed in master, so each release will contain a fe= w new=20 features and bugfixes; * The only freeze will be a message and docbook freeze, it will happen= for=20 the last two weeks prior to release (so we'll be in message/docbook fre= eze 50%=20 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 possi= ble to=20 the first day of that month; * Unlike previously, tags will be pushed immediately, we'll first tag = a rc1=20 and produce the tarballs, if no issue is found by packagers in a week t= hen it=20 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=20 exact dates for the freeze and release of the current cycle during the = first=20 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 o= wn: * Features in released modules can only be introduced in a very fine g= rained=20 way so as to not jeopardize the stability; * CI should be always green, breakages should be treated as stop the l= ine=20 events (all commits following a breakage should only be to try to get t= hings=20 back to normal); * There should be a strong focus on automated tests and peer review: a= ll=20 modified code should come with corresponding tests; if you got a framew= ork=20 which is low on test coverage because of its architecture it's likely t= ime to=20 focus on the tooling and test harnessing. Thanks for your attention. Regards. =2D-=20 K=E9vin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com --nextPart3232807.kIJa1ZbUJK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlNc0wsACgkQB0u7y43syeIcbgCfXf8Qqs+ZEdhFho+7QLquutrv OgUAnieR1sWlT39dogxCndBG9NHt8rf+ =zjgM -----END PGP SIGNATURE----- --nextPart3232807.kIJa1ZbUJK-- --===============7240117970650530650== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel --===============7240117970650530650==--