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.
loft =>
I was laughing before just because of my grief with gtk2 et al but I never thought that the cancer had spread to the entire Loonix organism. Took ten minutes at lunch to casually search Mr Pottering, holy shee-it. Pages and pages and pages of childish whining, bitching, and pointless trivial squabbling. I don't think I saw more than one or two remarks about the actual merits of systemd.
R4400
R4400
2xR12000
R16000
4xR16000
