Re: Imlib 1.3 released...

[Jim Pick <jim jimpick com>]

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

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

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

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.

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

Cheers,

 - Jim

PGP signature