Sorry to be late to the party.
hamei wrote:Within major versions they are supposed to be the same. If you have a library swahili-tagalog 1.1, and come out with an improved version 1.1a then it should do exactly the same thing but maybe with better spelling. So you should be able to replace 1.1 with 1.1a directly, is that not correct ?
No, not necessarily.
The major/minor versions of a library can mean two things:
- either the major/minor version of the software they are part of, which can be anything and only has a human meaning.
- or the major/minor version of the library interface embedded in the libfoo.so file (also known as the `soname').
What matters here, in order to get consumers of the library to keep working, is to take care of changing the major/minor versions only when needed, because keeping the existing tuple would actually break applications.
The usual rules, since the SunOS 4 days, are as simple as this:
- every time you add a new visible interface, you need to increment the minor version. This way, existing binaries linked against libfoo.so.42.0 will still run when linked against libfoo.so.42.1, and in fact the dynamic linker will prefer libfoo.so.42.1 over libfoo.so.42.0, but your new application using the new symbol will explicitely require libfoo.so.42.>=1 and will not run on a machine where you have not upgraded libfoo.so.42.0 to at least libfoo.so.42.1.
- every time you make an incompatible change to an existing interface (change the number of parameters of a function, change the layout of a public structure used by this function, remove a function), you need to increment the major version. This will prevent applications requiring libfoo.so.43.0 semantics to run with libfoo.so.42.* - they would be likely to dump core with this version.
Unfortunately, many shared library maintainers use the current project release as the soname, even if there are no interface changes, or, worse, even if there are interface changes requiring a major number change in a maintainance release. To be fair, most users don't understand this either, and getting angry ``why does your bollocks 4.38 release install libbollocks.so.72.0 and not libbollocks.so.4.38?'' is only funny the first two times.
In the `release early, release often' state of mind, interface changes will happen very often, and will theoretically require many different library versions. With a good packaging system able to remove orphaned libraries, this is bearable. The use of ELF symbol visibility, on ELF systems with modern toolchains, also help a lot, as this allows the visible interface to a library to be shrunk as much as possible.
Still, as long as software evolves, shared library version numbers will continue to evolve as well. And there is IMO nothing bad with this... as long as the versioning rules are understood and followed.
R3000 (alas, dead) R4000
x4 R4400 R4400
x2 R8000 R10000 R4000PC R4000SC R4400SC R4600 R5000SC R5000
x3 RM7000 2xR10000 R12000 2xR12000
- 2x2xR10000 R16000 4xR16000
among more than 150 machines : Apollo, Data General, Digital, HP, IBM, MIPS before SGI
, Motorola, NeXT, SGI, Solbourne, Sun...