[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE 3.2 release plan =?iso-8859-1?q?notice
From:       Martijn Klingens <klingens () kde ! org>
Date:       2003-06-15 10:59:54
[Download RAW message or body]

?Date: Sun, 15 Jun 2003 12:58:28 +0200
User-Agent: KMail/1.5.9
References: <200306141438.01544.nolden@kde.org>
In-Reply-To: <200306141438.01544.nolden@kde.org>
X-KMail-Link-Message: 139823964
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200306151258.32012.klingens@kde.org>
Status: RO
X-Status: Q
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 14 June 2003 14:38, Ralf Nolden wrote:
> Please see
>
> http://developer.kde.org/development-versions/kde-3.2-release-plan.html

Can't we make the RCs this time what they are supposed to be, i.e. candidate 
tarballs that to the best of our knowledge are suitable for release ?

This means the following changes in the schedule:

1) What is now called RC 1 in week 46 (November 9th) will be the "Final Beta" 
instead. We all know that that release results in quite a bit of showstoppers 
and can't possibly be called a 'release candidate' after all.

2) Instead of releasing RCs weekly we release them whenever we have no known 
showstoppers left. This means there are no fixed dates for the RCs, they are 
dependent on the amount of issues found.

3) The first RC that does not result in reports of new showstoppers will be 
used UNMODIFIED as the release tarball. Well, one change: add a CVS tag, but 
a diff on the code between the final RC and the release should be empty.

This will probably result in a sligthly longer period between the final beta 
and the release, but it also avoids most of the chaos around the way too 
arbitrarily chosen dates for shipping "release candidates" that are 
everything but release-worthy. It most likely also results in a more stable 
initial release, though it probably won't be enough to make the initial 
release of the quality that we until now reached in the x.y.1 point releases.

Looking at past releases all .1 releases are what .0 should have been. This 
can be achieved by releasing the final RC as RC, and branching CVS, but only 
release the .0 roughly a month after the final RC off the branch. Another 
option is to change our definition of 'show-stopper' to include more bugs so 
more need fixing before release too.

- -- 
Martijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE+7FFXyU99+Wby2cYRAsXCAJ93TDm/KuCsLURYj3XehT1i8QdahwCghuwd
KthCEeVLLpIe+jNWtKgsU1w=
=+1nU
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]