Versioning the 2.0 release

[Owen Taylor <otaylor redhat com>]

I'm sitting down to one of the last tasks for 2.0 now - bumping all
the version numbers.

For GTK+ and GLib this is quite straightforward ... just go through
all the files and change occurrences of 1.3 to 2.0. For Pango and ATK,
things are a little trickier because right now we are using libtool's
-release versioning rather than real shared library version numbers.

As a quick review, the way it has worked in the past for GLib and GTK+ is:

 - Each major/minor pair (GTK+-1.0/GTK+-1.2/GTK+-2.0) is considered  to
   be binary and source incompatible. To allow us to do parallel
   installs of development enviroments, we include the MAJOR.MINOR
   in the -l line (as generated by package config). So, the current
   GTK+-1.2 shared library on Linux (and other ELF platforms) is
   
    libgtk-1.2.so.0.9.1 [ -lgtk-1.2]

   And the GTK+-2.0 shared library will be:

    libgtk-x11-2.0.so.0.0.0 [ -lgtk-x11-2.0 ]

 - The three numbers after the '.so' are determined in the following
   way.

     Let Z (the micro version) be the last part of the GTK+ release
     (so 10 for GTK+-1.2.109)

     Let A (the interface age) be the number of releases since we last
     made additions to the interfaces.

   Then the libtool triplet "current:revision:age" is
   "Z-A:A:Z-A". With standard elf versioning, this produces a library
   name libgtk-X.Y.so.0.(Z-A).A

For the 2.x cycle, we are making a change in that we expect to release
binary and source compatible 2.2, 2.4, and maybe 2.6 releases and
number from 3.0 for the next binary/source incompatible release.

If we had had this plan from the beginning of the 2.0 release, we'd
presumably have gone with -lgtk-x11-2, but I'm not going to propose
going to this now, for a couple of reasons:

 - We've encoded 2.0 in a couple of user/programmer visible places
   (e.g., .gtkrc-2.0, gtk+-2.0.pc). Switching these at this point in
   the game wouldn't be popular.

 - One advantage of the 2.x naming is that it gives us a place
   to put the unstable development release leading up to 3.0 while
   remaining consistent .... libgtk-2.9.so.x.y.z.

We will, of course, get some questions from people who wonder why they
have libgtk-x11.2.0.so.0.211.3 on their system and see -lgtk-x11-2.0
when they installed GTK+-2.2, but well, the names are ugly enough
already that it may discourage people from trying to interpret them
:-)

For the .pc files, I think it might make sense to install symlinks to
gtk+-2.0.pc from gtk+-2.2.pc, etc. While this is just duplicating the
versioning support in pkg-config, it will make people feel better
about it.

We do need to decide how to handle the soname versioning as well while
maintaining binary compatibility between releases; one thing to do
would be to just abandon any relationship to the GTK+ release numbers,
so that libgtk-x11-2.0.so.0.5.2 for 2.0.7 is followed by
libgtk-x11-2.0.so.0.8.0 for 2.2.0; however, doing this doesn't give
any room for doing a maintanence 2.0.8. (We shouldn't generally need
to do this because we'll be maintaining bin-compat, but it's possible
that a 2.2.0 or 2.4.0 might be unstable enough for people to want to
stay back for a bit.)

So, instead, I'll propose numbering with libtool '(100*Y)+Z-A:A:(100*Y)+Z-A'
giving a soname of libgtk-X.Y.so.0.[(100*Y)+Z-A].A.

So, that's GLib and GTK+. So, what about Pango and ATK? Well, the
obvious, and probably right, thing to do is to use exactly the same
scheme. No matter how weird you think the above is, it's better two
have 1 scheme than 2 or 3. So:

 1.0.0                 => 1.0.7                 => 1.2.0
 libpango-1.0.so.0.0.0 => libpango-1.0.so.0.4.3 => libpango-1.0.so.200.0.0 => ...

And the same for ATK.

The two other alternatives are:

 A) Follow the same scheme but drop the .0 from the -l line, so:

 1.0.0               => 1.0.7               => 1.2.0
 libpango-1.so.0.0.0 => libpango-1.so.0.4.3 => libpango-1.0.so.200.0.0

 B) Use conventional library versioning (or libtool's modification of such), 
  and if and when we do an API incompatible version, then go to -lpango-2. So>

  1.0.0             => 1.0.7             => 1.2.0
  libpango.so.1.0.0 => libpango.so.1.4.3 => libpango.so.1.8.0

  (Note that the weird jumps:

    1.0.0 1.0.1 1.0.2 1.0.3 1.4.0 1.4.1 1.4.2 1.4.3

   are a feature of libtool versioning, not of anything unusual that we do for
   GTK+, GLib.)

Unless I hear a chorus of screams, and probably even then, I'm going
to go ahead with implementing the GLib/GTK+ scheme for Pango and
ATK... I think consistency is the most important virtue here.

Regards,
                                        Owen