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

[Havoc Pennington <hp redhat com>]

Martin Baulig <martin home-of-linux org> writes: 
> If the GTK+ team doesn't care at all about compatibility and even refuses to
> put such simple compatibility macros into GTK+ stable which I proposed, then
> can you please tell me a single reason why I should support any kind of
> compatibility in gnome-libs HEAD ?
> 

There is a big difference here.

You want us to add API to the stable branch to increase compat with
the unstable branch, so that apps can be "ported" to the new version
of the stable branch, allowing them to compile against both stable and
unstable at the same time.

We are opposed to that, for IMO good reasons which you did not respond
to that I see. (Well, Owen and I are opposed - Tim agreed with you,
which you seem to be missing.)

The issue about gnome-libs HEAD is simply backward compatibility,
which we have tried very hard to preserve when remotely possible.
i.e. your mail did not suggest any changes to GTK+ HEAD to make older
apps easy to port.

So we do care about compatibility of this latter type, i.e. BACKWARD
compatibility. This is what I mean by "compatibility."  You are
comparing apples and oranges by saying that slowly mutating the stable
branch into the unstable branch constitutes "compatibility."

If you want apps to build against both branches at once - which will
not work worth a damn, I'll go ahead and tell you - then just make a
custom header to use when porting, gtktransition.h, and use
that. There's no reason it needs to go in GTK+ at all.

So you are getting all hyped up and charging hypocrisy, but your
proposed GTK+ changes have NOTHING to do with compatibility. They are
hacks (e.g. #define G_OBJECT GTK_OBJECT) which make it easier to
maintain a single codebase which builds against both GTKs. This is a
Bad Idea (tm) to begin with; make a branch. There's a reason why we
have branches in CVS. But if you can't do that, again, put the hacks
somewhere other than GTK, there's no reason you can't do that.

Anyhow, this is purely a technical disagreement, we think those hacks
are not useful and bad for most users, you disagree, but mixing the
issue with gnome-libs HEAD makes no sense - the issues are completely
distinct because in one case we're talking about adding API to stable,
in the other about degree of breakage in unstable.

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers