[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: version and release number

From: Bob Friesenhahn
Subject: Re: version and release number
Date: Thu, 16 Apr 2009 09:43:09 -0500 (CDT)

On Thu, 16 Apr 2009, Lorenzo Bettini wrote:

Never try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. Instead, use the -release flag (see Release numbers), but be warned that every release of your package will not be binary compatible with any other release.

what I don't understand is the "not binary compatible": if I use, say 1.0 for the release flag (and the version number correctly as stated in the manual), and release another implementation of the library with the incremented version number but with the same release number, why won't it be binary compatible?

Or does "not binary compatible" apply only if I increment also the release number?

I sense some confusion. :-)

The -release option specifies part of the base naming for your library so that it becomes part of the base library name. For example, and To the operating system these libraries are completely different and might have well been named and The libraries might otherwise be entirely the same and could be "binary compatible" but the operating system won't know it. Very few packages use the -release option.

The -version-info option specifies library versioning information that the operating system will use when deciding which similarly named library to use. On most Unix systems, this forms the numeric part in the library file name after ".so". Different systems use different rules when deciding how to treat this version information. Assuming that libraries are from the same release, the correct library will be used as long as you follow the libtool rules when updating the -version-info argument.

There are many forms of "binary compatible". For example, a newer library might add a new function but otherwise be the same so an already existing application (using an older library) can safely use it. A newer application depending on the newer library could not safely use the older library since it might be using the new function the new function might not be present.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]