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

Dirk Mueller mueller at kde.org
Wed Jun 18 13:48:46 BST 2003

On Mit, 18 Jun 2003, Oswald Buddenhagen wrote:

> at this point it becomes obvious that we _know_ that RC1 won't be in a
> releaseable state, which means that it simply is no RC. what exactly
> speaks against calling these realease-non-candidates "pre"?

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. 

> btw, somebody has to explain to me, what this "The HEAD branch is frozen
> for feature commits that are not listed in the planned-feature
> document." stuff is supposed to be good for. either you get ready before
> the real feature freeze or you don't - so why put such an arbitrary
> restriction on spontaneous creativity?

Because of existing experience with previous schedules that didn't do that. 

> Start of Release Cycle: Preparing Pre-Alpha

There are very few users who install an alpha, if you call it 
pre-alpha nobody is ever going to test it. Most feedback comes from people 
who download and install the KDE binaries. And although the KDE project does 
not do nor support binary packages, it is the thing that matters to the end 
users. You cannot expect that any distro packager wastes time on packaging a 
"pre-alpha". Thats just not gonna happen. Very simple. 

> += 1 week: Pre2
> += 1 week
>   If no showstoppers are known by now, this will be RC1, otherwise
>   another Pre.
>   Repeat until success.

What do you do if a showstopper was introduced between pre2 and the thing 
you tagged as RC1 ?

Will you pull the release and rename it into pre3 then? Really?

Anyway, if we know about showstopppers, then there is no point in releasing 
it at all. Its ridiculous to put something out for testing as pre-release or 
release candidate when you already know that it has show stoppers. 

So effectively you agree to the established, traditional naming because your 
pre releases will never actually get released and only the release 
candidates will be put out. Case closed, nothing has changed. 


More information about the kde-core-devel mailing list