Managing compatibility and dependencies in code library

Question

I manage a library that is made of multiple components, there is some dependencies between some of these components, for example I have a core library for common code base that is referenced by other components. All of these components (including the core one mentioned in the example) are then packaged and pushed separately to a package manager for other developers to use. Backward compatibility is maintained when building any new version. So an assembly X who depends on assembly Y of version 1.0, won't have problems with assembly Y of version 1.5.

My question is, while all of the components evolve, how do I manage this network of dependencies to generate a matrix that says that version 1.0 or older of assembly X depends on version 1.0 or newer of assembly Y etc. Is there a well known approaches to manage this problem? I don't want to reinvent the wheel.

Answer 1

What you are referring to is colloquially called Dependency Hell and it has been a known problem since software became a thing.

The most IMO common solution to this is to use semantic versioning along with backwards compatibility. The basic idea is that all packages, including yours, define their dependencies not exactly but as "this or higher version". This way, the packages can be upgraded without breaking of functionality, assuming the packages maintain correct backwards compatibility.

• Sisyphus: I am sorry I wasn't clear enough about this point, but Dependency Hell is not exactly my problem, as all of the components are backward compatible already. I have modified my question to make it more clear.
• Euphoric: @Sisyphus I think many package managers either do have that function already, or provide APIs that make it easy to create an utility that can calculate this.