KDE 3.2 release cycle

Reinhold Kainhofer reinhold at kainhofer.com
Mon May 12 12:57:39 BST 2003

Stephan Binner wrote:
> You seem to wrongly assume that "time-based" means the actual release date
> and therefore no more beta/RC releases if there are too many errors? Then
> you're wrong. I mean the date of the feature freeze: Add only the
> features/programs which are ready at a given feature freeze date (that's
> like the last releases were managed). "Feature based" in opposite would
> mean to define the features that have to be in and then delay (endlessly)
> the freeze until all are there.

I have to agree here. As long as there is no feature plan freeze and feature
freeze announced, people will happily add new features and delay fixing
bugs until they absolutely have to. In kpilot, I have so many ideas for new
cute features, and I like working on them much more than fixing our bugs
(kpilot is rather high in the bug-count list, but many bugs are old or hard
to impossible to reproduce etc). Especially since I know the next release
will only be in almost a year or so, I don't have so much incentive to fix
bugs right now. 
I guess I'm not the only one thinking this way...

So, I'm all  for announcing a feature plan freeze relatively soon, so that
people really start planning which needs to get into 3.2.


More information about the kde-core-devel mailing list