On Mon, Jul 02, 2001 at 09:29:23AM -0700, Bill Studenmund wrote:
> On Tue, 22 May 2001, Bruce Momjian wrote:
>
> > I am always confused when to bump the minor and when the major. I also
> > was not sure how significant the change would be for apps. We added
> > const, and I changed the return type of one function from short to int.
> > Seems like ConnectionBad was also changed.
>
> You need to bump the minor whenever you add to the library. You need to
> bump the major whenever you delete from the library or change(*) the
> interface to a function. i.e. if a program links against the library, as
> long as the routine names it linked against behave as it expected at
> compile time, you don't need to bump the major.
>
> (*) NetBSD (and I think other OSs too) use a gcc-ism, RENAME, to be able
> to change the interface seen by new programs w/o changing the minor
> number. What you do is prototype the function as you want it now, and have
> a __RENAME(new_name) at the end of the prototype. When you build the
> library, you have a routine having the old footprint and old name, and a
> new routine with the new footprint and named new_name. Old programs look
> for the old name, and get what they expect. New programs look for the new
> name, and also get what they expect.
GNU binutils, Solaris ld, and other complete implementations of the ELF
standard also support "symbol versioning", which IIUC doesn't require
compiler support. This apparatus was used, for example, in Gnu libc to
add binary-backward-compatible support for a 64-bit file positioning
without need to change the source-level interface.
Of course just prepending a "new_" prefix would be a poor choice of
version naming convention.
It's possible to do this portably with elaborate macro apparatus, or (in
C++) with namespace aliases, but it's not pretty. Because it clutters
header files, it can be confusing to users who depend on header files to
supplement documentation.
Nathan Myers
ncm@zembu.com