From Newsgroup: comp.arch

On 4/8/26 3:25 PM, John Levine wrote:

According to Dan Cross <cross@spitfire.i.gajendra.net>:

Maybe he's thinking of what's known as DLL Hell, which resulted
from Microsoft's neglecting to put a version number in DLL filenames. ... >>

Quite possibly! It's interesting to note that Linux has also
suffered from similar issues, exacerbated by libraries that
don't handle versioning well. Containers were the solution.

That's kind of sad.

ELF library names include multi-part version numbers, with the plan being that
if the API changes you bump the major number, while if it's a bug fix or otherwise compatible you just bump the minor number.

One issue with this kind of version numbering is that adding a
feature is an API change but does not necessarily prevent
compatibility. This expression of versioning allows users
dependent on newer features to request the newer major version,
but it does not allow a newer major version to be used when it
is compatible (which might be desirable to reduce library bloat
or just not force installation of a different version).

While one could include a backward compatibility range (e.g.,
14-12 or 14b to indicate implementation of version 14 features
with compatibility back to version (b) to version 12), this
would still not maximize the compatibility support (which may
well not be a desirable goal).

Bug compatibility is also an issue as are leaky abstractions.
For ISAs, if early implementations use a stronger memory model
(or appear to do so), software could be written to exploit that
and be incompatible with future hardware.

One can also have performance (or non-time resource consumption) incompatibilities, where the abstract architecture is the same
but some uses may be significantly impacted. E.g., an ISA might
initially not define a preferred register zeroing idiom and
software might choose any single cycle instruction that zeros a
register, but later implementations might only optimize one of
those options.

(A library function that moved from a O(nlogn) implementation to
a O(logn) implementation with larger constant factor might
"break" software that calls the function N times rather than
once with an N-times larger list/array but be broadly considered
an improvement.)

Then you symlink the name
with the minor version number back to the name with just the major number so the
lists of imported library names just have the major number. This seems to work
OK on FreeBSD. What happens on linux?

I guess using minor version is tricky as it depends on the
specific implementation. The fourth bug fix version of Burzatt's
implementation of the 14th version of the libgood API would be
different than the fourth of Blinfoo's implementation. (There
could, in theory, be cooperation in minor versioning when a
common bug is discovered, but that seems unlikely.)

I guess the major version represents the abstract interface and
the minor version represents a "release number". With ISAs,
multiple resource-use targets (power-performance-area tradeoffs,
e.g.) might be pursued with the same abstract interface (the
original goal of Architecture), so specifying the interface
version number is not sufficient.

There may also be desirable for different implementations to
deprecate features (possibly where a feature technically works
but has poor resource use traits) or extend the lifetime of a
feature. E.g., an ISA version might specify that an opcode no
longer needs to be supported and can either generate an illegal
opcode exception or provide the legacy behavior while the
implementation could still claim to be of that version of the
ISA.

[I feel my mind is getting fuzzy, sleep is calling.]
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 18 Apr 2026 22:35:31 -0400, Paul Clayton wrote:

One issue with this kind of version numbering is that adding a
feature is an API change but does not necessarily prevent
compatibility.

This is why we distinguish between rCLAPIrCY changes and rCLABIrCY changes.

API changes which do not impact compatibility with existing binaries
built against that shared library do not require a library version
bump. ABI changes, which affect the generated code in some way (e.g.
increasing the size of fixed structures), require some kind of
versioning, either at the entire library level, or possibly just at
the individual symbol level.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 18 Apr 2026 22:35:31 -0400, Paul Clayton
<paaronclayton@gmail.com> wrote:

On 4/8/26 3:25 PM, John Levine wrote:

According to Dan Cross <cross@spitfire.i.gajendra.net>:

Maybe he's thinking of what's known as DLL Hell, which resulted
from Microsoft's neglecting to put a version number in DLL filenames. ... >>>

Quite possibly! It's interesting to note that Linux has also
suffered from similar issues, exacerbated by libraries that
don't handle versioning well. Containers were the solution.

That's kind of sad.

ELF library names include multi-part version numbers, with the plan being that
if the API changes you bump the major number, while if it's a bug fix or
otherwise compatible you just bump the minor number.

One issue with this kind of version numbering is that adding a
feature is an API change but does not necessarily prevent
compatibility. This expression of versioning allows users
dependent on newer features to request the newer major version,
but it does not allow a newer major version to be used when it
is compatible (which might be desirable to reduce library bloat
or just not force installation of a different version).

While one could include a backward compatibility range (e.g.,
14-12 or 14b to indicate implementation of version 14 features
with compatibility back to version (b) to version 12), this
would still not maximize the compatibility support (which may
well not be a desirable goal).

And does not address the possibility of gaps in the range of
compatible versions.

I have encountered this problem just a few times, but it has been a
nightmare each time: a new version changes some behavior in a way
that is incompatible with your application. Some versions later after
many complaints, the original behavior is restored [with new behavior
kept but moved to a new API]. Now there is a gap in the list of
compatible versions ... e.g., you can use versions C D E ... H but F
and G won't work.

Bug compatibility is also an issue as are leaky abstractions.

Yup!

For ISAs, if early implementations use a stronger memory model
(or appear to do so), software could be written to exploit that
and be incompatible with future hardware.

One can also have performance (or non-time resource consumption) >incompatibilities, where the abstract architecture is the same
but some uses may be significantly impacted. E.g., an ISA might
initially not define a preferred register zeroing idiom and
software might choose any single cycle instruction that zeros a
register, but later implementations might only optimize one of
those options.

Seen this too working with DSPs.

(A library function that moved from a O(nlogn) implementation to
a O(logn) implementation with larger constant factor might
"break" software that calls the function N times rather than
once with an N-times larger list/array but be broadly considered
an improvement.)

Then you symlink the name
with the minor version number back to the name with just the major number so the
lists of imported library names just have the major number. This seems to work
OK on FreeBSD. What happens on linux?

I guess using minor version is tricky as it depends on the
specific implementation. The fourth bug fix version of Burzatt's >implementation of the 14th version of the libgood API would be
different than the fourth of Blinfoo's implementation. (There
could, in theory, be cooperation in minor versioning when a
common bug is discovered, but that seems unlikely.)

I guess the major version represents the abstract interface and
the minor version represents a "release number". With ISAs,
multiple resource-use targets (power-performance-area tradeoffs,
e.g.) might be pursued with the same abstract interface (the
original goal of Architecture), so specifying the interface
version number is not sufficient.

There may also be desirable for different implementations to
deprecate features (possibly where a feature technically works
but has poor resource use traits) or extend the lifetime of a
feature. E.g., an ISA version might specify that an opcode no
longer needs to be supported and can either generate an illegal
opcode exception or provide the legacy behavior while the
implementation could still claim to be of that version of the
ISA.

[I feel my mind is getting fuzzy, sleep is calling.]

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

In article <10s1f1m$3mi35$1@dont-email.me>,
Paul Clayton <paaronclayton@gmail.com> wrote:

On 4/8/26 3:25 PM, John Levine wrote:

According to Dan Cross <cross@spitfire.i.gajendra.net>:

Maybe he's thinking of what's known as DLL Hell, which resulted
from Microsoft's neglecting to put a version number in DLL filenames. ... >>>

Quite possibly! It's interesting to note that Linux has also
suffered from similar issues, exacerbated by libraries that
don't handle versioning well. Containers were the solution.

That's kind of sad.

ELF library names include multi-part version numbers, with the plan being that
if the API changes you bump the major number, while if it's a bug fix or
otherwise compatible you just bump the minor number.

One issue with this kind of version numbering is that adding a
feature is an API change but does not necessarily prevent
compatibility. This expression of versioning allows users
dependent on newer features to request the newer major version,
but it does not allow a newer major version to be used when it
is compatible (which might be desirable to reduce library bloat
or just not force installation of a different version).

This is precisely the type of problem that so-called "semantic
versioning" (semver) is meant to solve: https://semver.org

It works decently well, as long as projects actually follow the
convention.

- Dan C.

--- Synchronet 3.21f-Linux NewsLink 1.2