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

[Oswald Buddenhagen]

On Wed, Jun 18, 2003 at 10:09:01AM +0200, Stephan Kulow wrote:
> OK, what's the difference between
> * "there will be two RC candidates, maybe more"
>
> and
> * "we plan exactly one RC, but are 100% sure there will be more"
> ?
> 
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"?
my understanding or the terminology is this:
- snapshot, pre-alpha: everything is open
- alpha: all (major) features are in place
- beta: there are no known major bugs
- rc: we honestly think that we can release it: the thing is virtually
  bug-free according to our best knowledge. only minor bugs in less
  prominent places are allowed.

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?

the changed schedule according to my ideas looks like this:

Start of Release Cycle: Preparing Pre-Alpha

 Please refrain from adding new features that interfere with (slow down)
 the development of features listed in the planned-feature document.
 Still, binary compatibility is not required, i18n string changes are
 allowed. KDE 3.2 Pre-Alpha [is tagged and] tarballs are made for testing. 

+= 1 week: Pre-Alpha release

 Pre-Alpha is announced. The sole purpose of this release is to provide
 a "technology preview".

+= 3 weeks: Preparing Alpha

 The HEAD branch is frozen for non-trivial features and is tagged as Alpha.
 Tarballs are released to the packagers. 

+= 1 week: Alpha release

 Alpha is announced. Hopefully it will be stable enough to be used by a
 wider audience. 

+= 3 weeks: Preparing Beta1

 The HEAD branch is frozen for any kind of feature commits.

+= 1 week: Beta1 Release

[ if the feedback from beta1 is so bad, insert another beta cycle

+= 2 weeks: Preparing Beta2

+= 1 week: Beta2 Release

]

+= 2-3 weeks: Pre1

 The i18n strings are frozen.
 Any non-trivial patches to CVS have to be approved by at least
 one other related developer.

 This is not called gamma or final beta, as it is not released. Still,
 packagers are encouraged to make experimental packages.

+= 1 week: Pre2

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

+= 1 week
  If no showstoppers are known by now, release 3.2, otherwise fix the
  bugs and create and create another RC (one or two days later).
  Repeat until success.
 

as you see, this is roughly the same as the previous schedule - just that
the terminology is more standard.

greetings

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.