[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic