[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE2 release schedule update
From:       Matthias Elter <me () caldera ! de>
Date:       2000-09-27 11:42:12
[Download RAW message or body]

On Tue, 26 Sep 2000, Waldo Bastian wrote:
(...)
> > - Immediately after the KDE2 v1.0 release a KDE_2_0 branch will be
> > created. Fixes to this branch will be released as KDE2 1.0.X versions
> > soon after the 1.0 release. The KDE_2_0 branch is not open for feature
> > commits.
>
> I don't think branches are a good idea because they tend to be tested very
> poorly. It effectively splits the developers across two branches. We had
> that situation between KDE 1.1.1 and 1.1.2 and only a few (3? 4?) people
> did actually work on 1.1.2.

I know that branching is not a perfect solution. But it is a fact that we 
will need a 2.0.1 release soon after 2.0. If we don't branch after 2.0 and 
open CVS for feature commits I don't see a bugfix 2.0.1 release happen all to 
soon. One possible solution is to keep the feature freeze after the 2.0 
release for another 4-6 weeks to make 2.0.1 happen. But I doubt that all of 
us have enough self discipline to respect that feature freeze. People 
(including myself) are tired of the freeze we have for month now.

KDE 2.0.1 aims to fix the most cirtical bugs in 2.0, nothing more. Those of 
us who are paid to work on KDE by a company who is interested to have a 2.0.1 
release soon after 2.0 (and I bet all distributors are) _will_ have to commit 
fixes to the KDE_2_0 branch.

> I also would like to see a split up of release schedules based on packages.
> This schedule still seems to be based on "release everything together". We
> want more releases more often and this schedules doesn't reflect that.

It is a rough road map, not a schedule. When I talk about KDE I mean the 
core. The core is kdelibs and kdebase. I agree with you that we don't want to 
keep up with releasing everything together. The road map simply gives a rough 
idea of when we might relase new versions of the core system.

(...)

> I can agree with this schedule if it was for 'kdelibs' but not for _ALL OF
> KDE_. E.g. kdemultimedia can release a new version in december and
> kdenetwork can have a release in januar. The pace of development for the
> different packages is quite different and the releases should be adapted to
> this pace.

kdelibs and kdebase, the base desktop. This does not mean that there can't be 
a seperate kicker release in say Februar, but you have to label the base 
system KDE 2.X somewhen.

-- 
    _____     ___
   /  __/____/  /                Caldera (Deutschland) GmbH
  /  /_/ __  / /__           Naegelsbachstr. 49c, 91052 Erlangen
 /_____//_/ /____/          Matthias Elter,  email: me@caldera.de
==== /_____/ ======   phone: ++49 9131 7192 300, fax: ++49 9131 7192 399
 Caldera OpenLinux                  http://www.caldera.de

[prev in list] [next in list] [prev in thread] [next in thread]