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 featur=
e
> > commits.
>
> I don't think branches are a good idea because they tend to be tested v=
ery
> poorly. It effectively splits the developers across two branches. We ha=
d
> that situation between KDE 1.1.1 and 1.1.2 and only a few (3? 4?) peopl=
e
> did actually work on 1.1.2.

I know that branching is not a perfect solution. But it is a fact that we=
=20
will need a 2.0.1 release soon after 2.0. If we don't branch after 2.0 an=
d=20
open CVS for feature commits I don't see a bugfix 2.0.1 release happen al=
l to=20
soon. One possible solution is to keep the feature freeze after the 2.0=20
release for another 4-6 weeks to make 2.0.1 happen. But I doubt that all =
of=20
us have enough self discipline to respect that feature freeze. People=20
(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=20
us who are paid to work on KDE by a company who is interested to have a 2=
=2E0.1=20
release soon after 2.0 (and I bet all distributors are) _will_ have to co=
mmit=20
fixes to the KDE_2_0 branch.

> I also would like to see a split up of release schedules based on packa=
ges.
> 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=20
core. The core is kdelibs and kdebase. I agree with you that we don't wan=
t to=20
keep up with releasing everything together. The road map simply gives a r=
ough=20
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 th=
e
> different packages is quite different and the releases should be adapte=
d to
> this pace.

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

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