[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:       Bernhard Rosenkraenzer <bero () redhat ! de>
Date:       2001-07-13 14:38:51
[Download RAW message or body]

On Fri, 13 Jul 2001, Torsten Rahn wrote:

> Correct me if I'm wrong but last time I talked to core-developers the
> idea was that for KDE 3.0 we break BC only where really necessary.

Please don't confuse Binary Compatibility (ABI) with Interface
Compatibility (API).
KDE 3.0 will break Binary Compatibility completely because of the switch
to Qt 3.0.0, which is almost fully interface (API), but not at all binary
(ABI) compatible with 2.x.

> After all one of the reasons why there are so many GTK-applications is
> that they had a more or less stable API for a long time.

That's because they didn't get any new releases out of the door. GTK 1.0
is totally different from 1.2, which is totally different from 2.0
(pretty much the only thing they all have in common is that I consider
them broken by design).

We have the choice between changing the ABI now (good idea: because of gcc
3.x, the ABI will change in any case. If the gcc people keep up with the
original plans, we won't need to worry about compiler-induced ABI changes
in the future - why not switch to Qt 3.0 at the same time?) and changing
it a couple of months later (sooner or later we will have to switch to Qt
3.0 -- if we do it after most OSes have upgraded to gcc 3.x, we'll break
BC twice).

> If we make KDE 3.0 anything beyond something that is slightly more than a
> recompile then you shouldn't expect that the number of KDE-applications will
> grow significantly over the next 9-12 months which would really bad in
> effect and which would push us quite a bit back.

Agreed absolutely - the change between the API and 2.2 and 3.0 should be
much like the changes between Qt 2.3.1 and 3.0.0: change the API only
where necessary, but add new classes/methods, change "static", "const" and
"virtual" qualifiers where it makes sense and other things that break ABI
but not API compatibility.

LLaP
bero

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