On Tue, Dec 02, 2003 at 04:09:04PM +0000, Thierry Vignaud wrote:
> Sven Neumann <[EMAIL PROTECTED]> writes:
> > > standard libray versioning scheme is to set soname to
> > > lib<name>.<major> (library being named lib<name>.<major>.<minor>
> > > on filesystem)
> > Don't get confused by the numbers, libgimp-2.0 is the library name
> > we've choosen. There is nothing wrong with that. It's just a name.
> > > if the a branch of a library is not compatible with the previous
> > > one, maintainer only has to bump its major. nothing more.
> > That's exactly what we are doing. Nothing more. Please have a look
> > at the versioning scheme I pointed you at. It does exactly what you
> > are suggesting.
> but it makes packaging harder for distros.
> both debian and mandrake (and even redhat now due to gtk+-1.2 to
> gtk+-2.x transition) use versionned packages for library (eg one can
> install libfoo2-1.0.1 and libfoo3-1.1.9 at the same time)
> this system works great for quite a number of libraries.
> but for libraries that include their version number into their soname,
> this makes packaging harder when one want to still be able to keep
> several versions of the same library.
This is what GTK+ does. libgtk-1.2.so.0 and libgtk-x11-2.0.so.0. GIMP
does the same thing as GTK+.
> since the major is not anymore unique (eg gimp-2.0.23 will provide
> libgimp-2.0.so.23 with the same major as libgimp-1.3.so.23 from
> gimp-1.3.23), we've to include version number into package name too.
No, you misunderstand. GIMP 2.0.0 will provide libgimp-2.0.so.0.0.0. GIMP
2.0.23 will provide libgimp-2.0.so.0.0.23. ABI will be maintained for the
the 2.0.x series (and possibly the 2.x series, if we decide to do that).
There are no ABI guarantees for 1.3.x since it's a development series.
As Sven said, we do break it. It is a development series, so you just
have to deal. When it hits 2.0, that's a stable series, and the ABI
will be maintained.
Note that GTK+ 1.3.x bumped the major so number at every release too.
Gimp-developer mailing list