KDE 3.2 release plan =?iso-8859-1?q?notice

[Martijn Klingens]

?=
Date: Sun, 15 Jun 2003 12:58:28 +0200
User-Agent: KMail/1.5.9
References: <200306141438.01544.nolden at kde.org>
In-Reply-To: <200306141438.01544.nolden at 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 at kde.org>
Status: RO
X-Status: Q
X-KMail-EncryptionState:  
X-KMail-SignatureState:  
X-KMail-MDN-Sent:  

=2D----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. candidat=
e=20
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 Bet=
a"=20
instead. We all know that that release results in quite a bit of showstoppe=
rs=20
and can't possibly be called a 'release candidate' after all.

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

3) The first RC that does not result in reports of new showstoppers will be=
=20
used UNMODIFIED as the release tarball. Well, one change: add a CVS tag, bu=
t=20
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 bet=
a=20
and the release, but it also avoids most of the chaos around the way too=20
arbitrarily chosen dates for shipping "release candidates" that are=20
everything but release-worthy. It most likely also results in a more stable=
=20
initial release, though it probably won't be enough to make the initial=20
release of the quality that we until now reached in the x.y.1 point release=
s.

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

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

iD8DBQE+7FFXyU99+Wby2cYRAsXCAJ93TDm/KuCsLURYj3XehT1i8QdahwCghuwd
KthCEeVLLpIe+jNWtKgsU1w=3D
=3D+1nU
=2D----END PGP SIGNATURE-----