Re: About compatibility in GNOME 2 (was Re: Compatibility stuff)

[Havoc Pennington <hp redhat com>]

Martin Baulig <martin home-of-linux org> writes: 
> Well, I don't think this is so much a difference.

We disagree on this point. ;-)

> What we want compatibility in gnome-libs HEAD for is to allow people to
> easily use their GNOME 1.x application with GNOME 2.0.

No! What we want is to make it easy to _port_ a 1.x application to
2.0. _Using_ a 1.x app with 2.0 doesn't make any sense. 

You can install 1.x and 2.0 libs simultaneously, so you can still use
1.x apps on a 2.0 desktop.
 
> But since these new macros and functions will be the same than the ones that
> are used in GTK+ 2.0, it'll be a lot easier to port the application to
> GTK+ 2.0 at a later point.

OK, so you still haven't explained why the app author can't put these
two lines of code in a gtktransition.h, if they insist on this course
of action. Then we don't create problems by adding API to GTK, users
aren't forced to upgrade, it doesn't require a GTK release engineering
cycle.
 
> However, since the right thing is to use the new gnome_entry_get_text() and
> gnome_entry_set_text(), I suggested in my porting document that we add these
> functions to the stable version of gnome-libs after GNOME 1.4.

OK, I disagree with that too, but obviously can't stop you. I don't
think we should be adding gnome-libs API in point releases.
 
> It'll just ease the final migration to gnome-libs 2.0 a lot if people are
> already using gnome_entry_get/set_text() in their GNOME 1.x
> applications.

Very few people are going to bother to port to "gnome-libs 1.4.1". We
are supposed to start porting to gnome-libs 2 at the end of the
month. I don't see where it gets us to be creating gnome-libs 1.4.1
compat functions at that point.
 
> Imagine you branch your application for GTK+ 2.0 and three months later
> you're running a diff between the two trunks. It'll make a big difference
> whether that diff changes stuff at 10 or at 326 different locations in the
> code. And when you ever need to merge a particular change from one trunk
> into the other, it'll even more make a difference whether you have 5 or 326
> changes.

A diff between stable/unstable branches is going to be huge; the one
between GTK 1.2 and GTK 2 is enormous. It's just inevitable. You
shouldn't create all kinds of odd hacks to maximize the unmodified
kLOC between branches. There are much more important things to worry
about.

Havoc