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

List:       kde-core-devel
Subject:    Re: What to do after 2.2?
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-07-15 11:11:28
[Download RAW message or body]

On Sunday 15 July 2001 11:51, Peter Kelly wrote:
> I would certainly agree on this point.... I think having a 2.3 version
> will be very important from the point of getting a stable and relatively
> bug-free version of khtml. Right now there are over 700 open bug reports
> for khtml and kjs combined. A few more months and a 2.3 release would
> hopefully mean we can get the majority of issues sorted out.

As far as I understood it the KHTML won't be rewritten in KDE 3.0 as is was 
for 2.0. It will just continue to evolve using the same code base. Hence open 
bugs are still applicable and can still be fixed.

Chances that KDE 3.0 will have _at least_ KDE 2.1's stability are quite big 
given the fact that nobody plans completely new technology.

Maybe I'm wrong here, but if we can indeed manage a release cycle that is at 
most a couple of months longer between 2.x and 3.0 than between 2.x and 2.y 
we can have 3.0 out of the door this year. Then 2002 will be a _very_ 
promising year for us because we can start with all new technologies of the 
last 2 years Qt and then last year KDE that suffered from BC issues and still 
have quite a decent stability from the start.

My only concern would be if our release schedule is similar to that of the 
2.4 Linux kernel, i.e. a one-year delay would happen. That is the only 
convincing argument for not doing 2.3 now. OTOH, this entire discussion is 
caused by the fact that it took us a year since Qt 2.0 to get KDE 2.0 out of 
the door, so essentially the late 2.0 release is the problem and not the 
early start with 3.0. If we can now sync our releases with Qt then we're up 
to date again and have another 2 years or so to extend on that code base 
before Qt 4 will rise his head.

Probably the best argument was mentioned by Neil a few days ago:

On Friday 13 July 2001 22:56, Neil Stevens wrote:
> In a sense, it seems to be a no-win situation.  If we delay KDE 3, we'll
> lose some third party developers to Qt 3.  If we go ahead with KDE 3,
> we'll lose some third party developers to frustration.  Since we lose 
> either way, let's go with the decision that benefits KDE with new features
> and languages, and minimize our losses my reassuring our third party
> developers that we'll do better next time.

That perfectly covers everything: both approaches have serious drawbacks, but 
on the long run the drawbacks of switching to KDE 3.0 are less severe. For 
the short run it seems like both ways are bad, and maybe even opting for 3.0 
is worse than going for 2.3, but on the long run that is definitely not the 
case.

> Assuming there will be a considerable time before the 3.0 release, it

Seems like nobody wants that, though! So unless people start doing all sorts 
of Bad Things (tm) when we start doing 3.0 the release cycle won't be much 
bigger than the time between 2.2 and 2.3.

> will mean that there will be a "stable" version of khtml out there that
> people can use while bigger changes & feature additions are taking place
> for 3.0. Assuming other apps take the same path, we can then take our
> time with 3.0 and make any major architectural changes etc. there instead.

We don't want to do _major_ architectural changes because they would break 
source compatibility too much. We need to break BC to make some methods 
virtual and clean a few bits up, and to add some methods, but that's about 
it. And we need to break BC anyway during the switch to GCC 3.0 and 
personally _I_ want a switch to Qt 3.0 soon as well. Only the new style 
engine, the new RegExp engine and the new RichText engine already justify 
that for me, and then I don't even mention the fact that you can finally load 
.ui files on runtime using QWidgetFactory and the support for Hebrew and 
Arabic text, amongst even more improvements.

> > 3. Many people want to add their features which they worked on while KDE
> > 2.2 is in feature freeze session (examples - Staikos on security, kentz
> > on KDE installer, and the fonts installer [forgot the author name -
> > sorry]. Telling them to drop everything they did while it was feature
> > freeze because we're moving to 2.9/3.0 is definately not nice and
> > definately unprofessional..

Hmmm? What's the difference between integrating the same code in KDE 3 or in 
KDE 2.3? The entire idea is to port quickly the source incompatible bits and 
then have mostly our normal release cycle, with as the only difference that 
we are this time free to add/remove data members and virtual methods. But 
that is BINARY compatiblity and the entire point is that BC will be broken 
soon anyway and hence we can better take the same train.

> > If we'll have 2.3 release around October/November - then we'll have 2 new
> > things that can definately assist us:
> >
> > 1. QT 3.0 final version - tested, ready to use

Only somewhat important for the style engine, because that API is not stable 
yet. But the style engine is completely separated from the rest of KDE and 
thus doesn't affect any decision at all.

The counter-argument is that if we do that the KDE 3.0 release will be out 
many months after Qt 3.0, so we will have this same discussion again for Qt 
4.0 and so on. Besides, many apps will or might switch to Qt 3 instead of KDE 
3, so we essentially get Qt and KDE apps instead of mostly full KDE apps. 
Just like Gtk apps vs. Gnome apps. We don't want that, don't we? kvirc 
already went this way and other apps are sure to follow if KDE 3 takes too 
long after Qt 3.

> > 2. GCC 3.0.1 - I know that most distributions want to use it, but 3.0 is
> > not exactly a production stable, so all the distributions are trying to
> > fix all the bugs until 3.0.1. My guess is both Mandrake and Redhat will
> > be out with gcc 3.0.1, SuSE will follow and at the end of the trail -
> > Debian and Slackware - so we'll have a perfect compiler to use and skip
> > those BC problems (twice, one with QT and one with GCC as bero pointed
> > out).

No, we would introduce them twice instead. First because you get all distros 
running KDE 2.x compiled on GCC 3.0, which breaks against the older GCC 2 
based distros. And then again when KDE 3 is out.

> > 3. Thats only maybe - but I hope that the OpenSSL guys will finally
> > release 1.0 version - each release they break BC...

But that one would affect 2.x as well.

Martijn

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