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