Re: Imlib 1.3 released...

[raster redhat com]

On 23 Apr, Jim Pick shouted:
->  
->  raster@redhat.com writes:
->  
->  > Well miguel wanted a major change in data structs :) - it probably wont
->  > affect anyone in gnome/gtk etc.. but i still advise a recompile....
->  
->  That's a given.  You can't fix 1.3 now.  I'm just trying to explain it
->  to you so you can properly version the libraries on future stable
->  releases so people can have confidence in using them.
->  
->  > ->  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.
->  
->  Yes.  If Imlib 1.2 was a stable production release - you should not
->  break compatibility under any circumstance - unless you increase the
->  version number.
->  
->  I'm concerned because you haven't responded with any sort of
->  acknowledgement that you either:
->  
->  a) intend Imlib to be a unstable development release, and are reserving

it is stable... no crashes or memory leaks / memory corrumption known.

->     the right to not change the major version number - because nobody
->     should be using it in production programs.  I guess you are implying
->     that by your last statement - but you haven't put a warning into your
->     release announcement saying this is so (or said so publicly).  This
->     really, really needs to be communicated.

I know ALL programs that use the Xlib Imlib - it doesn't matter.

->  b) now understand that you need to increment the major version number when
->     you break compatibility in a production library.

I just have a major aversion to the sudden increas in lib version
numbers.. call it personal. too late now and its a moot point and it
wont affect anyone - VERY VERY VERY few people wil eb affected - only
those who use the X11 imlib will be affected. NOT the GDK version - so
the whole point is moot. - and even then only if they start digging
thru imlib's ImlibData structure...

->  
->  I still get the impression that you are trying to match the soname to
->  the version number on the release of the package.  That isn't

YEs.. it's SOOOO much neater :) you have NOt idea how badly users get
confused as to what version they have instaleld fo somehting if the
soname does nto match the realase version.

->  necessary.  I don't really care if you increase the major version on
->  soname of the library with every minor release you make.  They don't
->  need to be synchronized.
->   
->  > ->  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.
->  
->  You can't blame Miguel for breaking compatibility in a production
->  library causing production apps to fail.  You could have cleanly broke

I am not blaming him.. he asked for a change.. I made it. it changed
the size of a data struct that no program you use or write even has
access to. It only affects the Xlib version If you poke in the
ImlibData struct.

->  compatibility by incrementing the major version number of the soname.
->  If you did that, than a user using an app that is several weeks old
->  can rely on that app working forever.
->  
->  Again, if it isn't a production library, it's no problem breaking apps
->  - but you haven't communicated that fact.

In the release note.

->  And if it isn't a production library, I'm going to abandon trying to
->  get some stable Gnome 0.13 packages built, and concentrate on getting
->  some snapshots working.  I know a lot of people would be disappointed.

see above.

->  Sorry to be such a pain - but I am probably the person most affected
->  by this.  (And you of course, because you get a 'bad rep' for
->  releasing stuff that doesn't stay working, when everybody else's stuff
->  keeps working.)

actualy if you check the changes you will see you are completely
unafected.:) Now.. back to code.

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