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

[Martin Baulig <martin home-of-linux org>]

Owen Taylor <otaylor redhat com> writes:

> First, let me apologize for the tone of my original mail.  It clearly
> was over-emotional for a response to a well-intentioned proposal
> 
> In a lame defense of my language, I'll say that much of the problems
> that were seen in the pre-1.0 GNOME days were from people trying to
> target multiple versions of GTK+. There was plenty of code that looked
> like:

Hi Owen,

well, maybe you misunderstood my proposal a bit.

Like I already explained a bit in my previous mail, my idea was to

a) GTK+ 1.2.10 will add a some new macros and functions. These functions
   will be the same than the ones that will be used in GTK+ 2.0.

b) In Bonobo, we require GTK+ >= 1.2.10.

c) We port Bonobo to use these new macros and functions.

So now we have a reached a version of Bonobo which will compile with
GTK+ 1.2.10 and which will still be binary compatible with the previous
version of Bonobo. And this version of Bonobo can be ported to GTK+ 2.0
with just a few changes.

d) We branch Bonobo and port it to GTK+ 2.0 in the HEAD.

This model has the big advantage that the number of changes between the
stable branch and the HEAD will be very small. So when you need to merge
back stuff at a later time, this'll be very easy.

If you branch Bonobo first and then do all the GTK+ changes, you'll get
a very large number of changes between the two trunks and it'll be very,
very hard to merge changes from stable to the HEAD at a later time.

> In terms of trying to convince maintainers to port to gnome-libs-2 - I
> don't think there is an issue. The plan at the current time is that by
> GUADEC, two things will have happened:
> 
>  - We'll have released GNOME-1.4
> 
>  - The GTK+-2.0 API will be frozen.
> 
> At that point, we'll branch all GNOME libraries into a stable
> GTK+-1.2/gnome-libs-1 version and start porting everything over.

We'll still have the problem that people will want to continue developing
their GNOME 1.x libraries and applications. The main problem I see here
is that you cannot port a GNOME 1.x application to the GNOME 2 platform
without making it unstable (because the GNOME 2 platform is by its definition
unstable at the moment).

So people will want to keep their GNOME 1.x applications and libraries and
they will also want to continue developing them.

I don't see what's so wrong with using a set of new "compatibility" functions
in GNOME 1.x code if that'll limit the number of changes which will need to
be done later.

> What we don't care about is forwards compatibility - I'm strongly of
> the opinion that when you are experiencing the pain of porting to
> GTK+-2.0, you should not have to simultaneously worry about backwards
> compatibility with all the brokenness that was in GTK+-1.2.

Well, I'm still waiting for someone to explain me what exactly the difference
is here. Let's choose the GnomeEntry example here.

i)  backwards compatibility:

      A GNOME 2.0 library will work with GNOME 1.x code because it supports
      the GNOME 1.x API.

      In gnome-libs HEAD, it's no longer allowed to use gnome_entry_gtk_entry()
      and to suck things out of the GtkEntry directly, it does not support this
      API any longer.

      Instead, there are two new accessor functions, gnome_entry_get_text() and
      gnome_entry_set_text().

      So gnome-libs HEAD is not backwards binary compatible with GNOME 1.x.

ii) forward compatibility:

      A GNOME 1.x application or library will work with GNOME 2.0 without
      making any changes.

      I suggested that we add gnome_entry_get_text() and gnome_entry_set_text()
      to gnome-libs stable.

      This would mean that gnome-libs stable would become forward compatible
      with gnome-libs HEAD (*).

You guys seem to be concerned about backwards compatibility in GNOME 2.0 and
you don't seem to care about forward compatibility in GNOME 1.x.

Ok, so let me show you ii) implies i) and it's done. Or do I miss something ?

So, let's assume

* gnome_entry_get_text() and gnome_entry_set_text() has been added to
  gnome-libs 1.4.1

* Application Foo is only using gnome_entry_get/set_text() and not using
  gnome_entry_gtk_entry() at all.

* Application Foo is using gnome-libs 1.4.1 and has not yet been ported to
  gnome-libs HEAD so that it's still part of the GNOME 1.x platform.

And now let's look at gnome-libs HEAD again. Foo is a GNOME 1.x application
and it is not using gnome_entry_gtk_entry(). This means that gnome-libs HEAD
supports all of the API that is used by Foo.

Conclusion:

There is at least one GNOME 1.x application X and gnome-libs HEAD is backwards
compatible with X. Since Foo was any GNOME 1.x application, so ii) => i).

So, what's now the difference between backwards and forward compatibility ?

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)