I have different versions of modules and they should all work together with the same shared library which could also have different versions like displayed in the image below:
From a daily use perspective, should I
- always use the latest version of the Shared Library for every Module
- create a framework that allows using different versions for each module?
The 1. would have the disadvantage that with every change of the shared library, every module has to be tested.
The 2. has the disadvantage that mapping the dependencies can get a bit hard to manage
Best Answer
You asked this in a pretty broad fashion, so here is an equally broad answer: it depends. In smaller systems, #1 will be usually desirable, since it reduces configuration management efforts and complexity to have each lib only in one version in the system. For example, if a bug has to be fixed in a shared lib, it will only have to be fixed in one place. Devs have only to keep the newest API version of the lib in mind, deployment maybe simpler, and shifting code from one module to another will become simpler.
However, this does not come for free: exchanging a certain lib by a newer version will require
a test of all dependent modules
a recompilation when using a compiled language environment
and if the new version of the lib contains breaking changes, some modifications to their client modules.
These efforts can be small when the lib in stake is well designed for backwards compatibility, or when there are only a few depending modules, or when the interface of the lib is not huge.
However, the larger a certain system gets, and the more a library is reused in different modules, the more likely it will become necessary to use approach #2, at least for some of the shared libs. When the software is large enough to have different teams or sub-teams working on different modules, and/or those modules have different release cycles, at some point sticking with #1 for each and every lib will increase the mentioned efforts to a point where it simply will become more economical to use model #2.
Note that model #2 bears a certain risk of introducing technical debt into a system - if at some point in time older versions of the shared lib cannot be used any more (maybe for security reasons, for incompatibilities with newer OS or hardware versions, or maybe for contractual / licensing reasons), you may be forced to refurbish large parts of the system to make it compatible with the newest lib version.