Re: Imlib 1.3 released...

[Jim Pick <jim jimpick com>]

raster@redhat.com writes:

> ->  I'm just about to compile some stuff with gdk-imlib 1.2.
> ->  
> ->  If imlib 1.3 is "released code" (versus pre-release code) as the version
> ->  number suggests (unless I misunderstand the versioning scheme) -
> ->  wouldn't it be much better to increment the major version number in
> ->  the SONAME of the library rather than forcing everybody to recompile?
> 
> the soname is bumped up to 1.3 form 1.2.. its not major.. but the api
> is still the same thu no majore revision.. maybe your and my ideas
> about minor and major versins are different.. :)

Let me think ...

It's basically a standard convention - when the major number
increases, that signifies a break in compatibility.  So you know when
to keep multiple versions of the library around.

That's why the Linux dynamic linking system works - where Microsoft's
DLL system has big versioning problems all the time (Microsoft must
always maintain backwards compatibility).

ie. if you were following this convention, and imlib 1.3 bumped up
it's soname to 2.0 (because it was incompatible) - the respective
Debian packages would be:

gdk-imlib1_1.2-1.deb
gdk-imlib2_1.3-1.deb

So applications that depend upon gdk-imlib1_1.2 could be mixed with
applications that depend upon gdk-imlib_1.3.  That's fairly important
in the case of Debian, because there are different maintainers - and
they can't release all of their packages 'in sync' with the libraries.
For Red Hat, that isn't as much of a problem (except for the contrib
guys).

You could choose to break the convention - and say that every minor
version number denotes a compatibility break.  But then we'd have to
name the packages like this (which is non-standard):

gdk-imlib1.2_1.2-1.deb
gdk-imlib1.3_1.3-1.deb

Now, I think it is perfectly within your right to break compatibility
without raising the major version number if imlib 1.2 was basically a
pre-release development build.  But if you're releasing it for people
to use in production applications - you don't win any friends when you
break compatibility.  If imlib is still under active development - it
should be made pretty clear if that is the case (the current version
numbering scheme looks like they are production releases).

> ->  You do this so the old version and the new version can be installed on
> ->  the system at the same time.
> ->  
> ->  Imlib isn't ready for production apps if you introduce new versions
> ->  that will break compatibility on existing "production" apps installed
> ->  on the system.  That's what the library versioning is there to fix.
> 
> either way.. everyone re-compiled gnome every day anyway.. you have to
> just to make sure it runs. :)

I'm still trying to release some Gnome 0.13 packages so the Debian
folks can try them out.  The imlib maintainer just uploaded imlib 1.2
packages yesterday.  I just realized with your announcement that if I
build them with imlib 1.2, and upload them, they are going to blow-up
on everybody as soon as the imlib maintainer uploads imlib 1.3
packages.  That means my work might only be good for 24 hours, then I
have to recompile again.  Arrgh.  And then if you do the same thing
for imlib 1.4, I have to recompile again.

It would be nice to have some stable Gnome packages that the Debian
folks could try.  Now that Gtk 1.0 has been released, it would only
take a stable release of gdk-imlib where a newer stable release
wouldn't break compatibility.

If imlib isn't yet ready for a prime-time release, I understand.

Cheers,

 - Jim

PGP signature