Contributed by Satoshi Asami
<[email protected]>, Peter Wemm
<[email protected]>, and David O'Brien
<[email protected]>.
9 December 1996.
If you are adding shared library support to a port or other piece of software that doesn't have one, the version numbers should follow these rules. Generally, the resulting numbers will have nothing to do with the release version of the software.
The three principles of shared library building are:
For instance, added functions and bugfixes result in the minor version number being bumped, while deleted functions, changed function call syntax etc. will force the major version number to change.
Stick to version numbers of the form major.minor (x.y). Our dynamic linker does not handle version numbers of the form x.y.z well. Any version number after the ``y'' (ie. the third digit) is totally ignored when comparing shared lib version numbers to decide which library to link with. Given two shared libraries that differ only in the `micro' revision, ld.so will link with the higher one. Ie: if you link with libfoo.so.3.3.3, the linker only records 3.3 in the headers, and will link with anything starting with libfoo.so.3.(anything >= 3).(highest available).
Note that ld.so will always use the highest "minor" revision. Ie: it will use libc.so.2.2 in preference to libc.so.2.0, even if the program was initially linked with libc.so.2.0.
For non-port libraries, it is also our policy to change the shared library version number only once between releases. When you make a change to a system library that requires the version number to be bumped, check the Makefile's commit logs. It is the responsibility of the committer to ensure that the first such change since the release will result in the shared library version number in the Makefile to be updated, and any subsequent changes will not.