See my reply above. soapysdr is not an application; it’s a library. The version number is included because there are different, mutually incompatible, ABIs provided; giving the packages different names in this case allows the dependencies between the library and an unknown number of application packages that were built against it to be correctly expressed, while still allowing for ABI-compatible upgrades of the library to happen where possible. It also allows you to have two different copies of the library providing different ABIs installed in parallel.
See also: shared library “.so names”
The Windows equivalent would be… I guess differently named DLLs for different incompatible versions of the common redistributables, or more generally “we give up and don’t have a packaging system so every application will just include their own copies”
That would be easy to do by incorporating the version number INSIDE that library. In this way it won’t brake the app, that use that library, at every upgrade. It can include even more than just that.
Apps can check also the library version and don’t “upgrade” if not compatible.
Windows DLL and EXE files have that smart mechanism to include usefull info in their header: https://support.microsoft.com/en-us/help/913111/how-to-use-the-filever-exe-tool-to-obtain-specific-information-about-a
And yes sometimes they become deprecated and name is not used by other newer DLL’s. Like Nvidia’s CUDA-based video encoder called nvcuvenc.dll that become obsolete (and newer drivers don’t have it) when hardware encoders started to be integrated in GPU’s with Kepler family.
I don’t think you understand the package management system, and I’m not really interested in arguing about this.
(I’d note that shared libraries do have internal versioning - soname and versioned symbols - but that is not really what the packaging strategy is about)
