KDE 3.2 release plan=?iso-8859-1?q?notice
Martijn Klingens
klingens at kde.org
Thu Jun 19 21:17:43 BST 2003
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 18 June 2003 14:48, Dirk Mueller wrote:
> Oh boy. We really don't label things RC1 when we know that its not a
> release candidate. But somewhen you have to start, otherwise we will never
> release. And experience shows that the first try is always screwed up. Its
> not that we plan that this is going to happen, its just that its being
> honest to admit that Murphy's Law applies to the KDE Project as well.
Even then you can't plan RC2 beforehand since you never know how much time it
takes to fix all issues found in RC1.
Also, I agree that there are *always* issues with what we used to call 'RC1'.
that's why I proposed to call it 'Final Beta' instead and use it as the mark
of the RC cycle. Based on the issues found with the Final Beta we can then
release RC1 when all showstoppers in the Final Beta are fixed.
If new issues are found we go through the process again and release an RC2,
RC3, etc.
The key however is that we NEVER release with known showstoppers.
Lastly, the final release is IDENTICAL to the last RC. If the last RC wasn't
good enough to be final release we need another RC. Simple.
All this ensures that the tarballs that we do release contain a lot more
quality and that the final release likely will be more stable as well.
For the schedule this means the following:
* "RC1" will be labelled "Final Beta". Dates don't changes, rules don't
change, just the name we give the thing.
* "RC2" (which will be called "RC1" as it's now the _first_ RC) has _NO_ set
release date. It will be released whenever it's done. This can be a week
after the final beta (or less, but you need time to wait for potential
issues to get reported), but it can just as well be 3 months later. It does
not matter WHEN it will be released, but whenever it is it has NO KNOWN
SHOWSTOPPERS.
* Final is released whenever we have an RC that doesn't result in new
showstoppers for a week. The tarball is identical to the last RC's tarball
and the KDE_3_2_0_RELEASE tag is made equivalent to KDE_3_2_0_RCx tag.
The final release date as such is no longer known, but chances are fairly high
that either it will be the same date, or the release is delayed to get more
stability in, which can't be back either.
- --
Martijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
iD8DBQE+8hpqyU99+Wby2cYRAsWjAJ4uynNcUqbIkHvKHwq/VYzPkqMlFgCgpVpL
dbnq8alvpIlsYSXiuPvZymE=
=htim
-----END PGP SIGNATURE-----
More information about the kde-core-devel
mailing list