Re: Imlib 1.3 released...

[raster redhat com]

On 22 Apr, Jim Pick shouted:
->  
->  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).

Well miguel wanted a major change in data structs :) - it probably wont
affect anyone in gnome/gtk etc.. but i still advise a recompile....

->  > ->  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.

just rebuild the packages.. no big deal.. we do that every day for
rpm's here - it's not hard.

->  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.

Well If miguel hadn't wanted those chanegs there wouldnt have been a
problem.. as far as i can tell 1.2, and 1.3 are stable - 1.3 came out
with some added features and a change to reduce memory consumption on
non 8bpp machines - which will finally be pretty arbitary as Imlib
someday will become a server not jus a library.

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

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/