Release dates/nomenclature

[Troy Unrau]

So, I've brought this proposal up once before, but here it is again
(in more concrete form, and no misleading terminology). This email
will make some people unhappy since it indicates that we will be
missing the Oct23rd date which is a nice date for historical reasons
only (KDE 2.0 was released on Oct 23rd as well).

We will not be able to obtain a decent release on Oct 23rd despite
everyone's best wishes, including my own. Hell, the plasma panel will
miss this, the last beta, and unless the extra beta is inserted, will
never see the panel in a beta series release before Oct 23rd.

So here are the adjustments I'd like to see made, on behalf of the
marketing working group, and for the general sanity of having a beta
with a mostly-functioning plasma before we freeze:

1) We add another beta into the release cycle pushing the release
candidates back. This ensures that we actually have a beta with the
plasma panel and not kicker.
2) We add an additional two RC's (for a total of 4 RCs) to ensure that
the code works, and isn't a festering dung-heap when we release it.
3) We call the Nov 22nd RC3 as the "KDE 4 Technology Platform
Release". We then take the extra month afforded by the additional RCs
for documentation, translations, unit tests, artwork and bugfixes ONLY
(deep freeze).
4) We tag 4.0.0 just before Christmas, have a relatively quiet
announcement of 4.0.0 'being tagged', branch and reopen trunk.
5) We announce the 4.0.0 release January 17th in Mountain View. The
distros have had four weeks to get a handle on it and they all have
packages ready to use. Some initial reviews and such will already be
live before our announcement.

The new schedule would look like:

September 25: 3.94 (KDE 4.0 Beta3)
October 23: Total Release Freeze
October 25: 3.96 (KDE 4.0 RC1)
November 8: 3.97 (KDE 4.0 RC2)
November 22: 3.98 (KDE 4.0 Technology Platform Release a.k.a. RC3)
December 6: 3.99 (KDE 4.0 RC4)
December 20: 4.0.0 tagged, is unannounced except to distros-- 4.0.x
branched, trunk unfreezes...
January 17: 4.0.0 announcement and release party

If it makes you happy, think of the Technology Platform Release as
RC3, only we will at this point start to tell early adopters that it's
ready, and distros that like to live on the edge a little can use it.

Here's why we care, in marketing, for the extra beta and RC's, even
though that means 4.0.0 is pushed back:
- stability is important - we can have all the cool features in the
world, but when we ship 4.0 out the door and the bad reviews come in
due to instability, we will have a long uphill battle against the
negative public perception that 4.0 is buggy.  If we can pull off a
smooth 4.0 release, we can avoid much of the bad publicity.
- first impressions are important - if we don't have a relatively
polished release, the first reviews will be bad, and we'll not have a
drove of users trying out KDE for the first time.  These reviews have
to be good for users to pay attention.
- people on IRC are calling this week's beta as alpha4 because of the
quality. Seriously folks, it's pretty bad. Some KDE community members
are recommending against using 4.0 already are claiming that they
won't even use it themselves. This is terrible for convincing people
to migrate early - having our own community complaining about the
release looks terrible.

People will argue that a major point-oh release is never stable, but
really folks, can't we afford two extra months to make it worth
releasing? If anyone honestly believes that we'll need more than the
extra two months, we will need to reschedule the release party now
before flights are booked.

Cheers folks

-- 
Troy Unrau
Geophysics Student - University of Manitoba
KDE Gearhead