Re: Imlib 1.3 released...
- From: raster redhat com
- To: jim jimpick com
- cc: e-develop rasterman com, e-announce rasterman com, gnome-list gnome org
- Subject: Re: Imlib 1.3 released...
- Date: Mon, 27 Apr 1998 14:51:26 -0400 (EDT)
On 23 Apr, Jim Pick shouted:
-> firstname.lastname@example.org 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
-> 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.
-> 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.
-> - Jim
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
email@example.com /\___ /\ ___/||\___ ____/|/\___ firstname.lastname@example.org
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/
] [Thread Prev