3

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:

modules with shared library

From a daily use perspective, should I

  1. always use the latest version of the Shared Library for every Module
  2. 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

Improve this question
9
  • 1
    Can't you use the same version of the library for all modules without always using the latest?
    – Ben Cottrell
    Commented Aug 6, 2021 at 16:35
  • 2
    2 is the only one that actually works if you have breaking changes
    – Ewan
    Commented Aug 6, 2021 at 17:07
  • 1
    What do you mean by "module"? Do modules A, B, and C form a single application? Or are they three separate applications? Are they always distributed together or can you have different combinations of A, B, and C?
    – Thomas Owens ♦
    Commented Aug 6, 2021 at 17:16
  • @BenCottrell sometimes a Module needs a bugfix in the Share Library, then the newest version has to be used at least in that one
    – TomatenSalat
    Commented Aug 9, 2021 at 9:26
  • @Ewan adapting all the Editors to work again with those breaking changes would also work, but it is a lot of work depending on how big the changes are. after certain cycles the newest versions of the Shared Library have to be used anyways to avoid the technical dept that Doc Brown mentioned below
    – TomatenSalat
    Commented Aug 9, 2021 at 9:29

1 Answer 1

Reset to default
3

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.

Improve this answer
5
  • Can you please put "larger system" into a quantifiable context? I mean it doesn't have to be very precise but are we talking about 20 modules or 100 modules? Also what do you think about the idea of just having just 2 versions of the shared library, the frozen one with which all modules have been tested and one that is updated?
    – TomatenSalat
    Commented Aug 9, 2021 at 9:37
  • 1
    @TomatenSalat: maybe you can start by putting your question into a context first?
    – Doc Brown
    Commented Aug 9, 2021 at 9:38
  • 2
    ... the "number of modules" alone is no useful metrics. Two modules alone can be enough to require a shared lib in two versions, depends all on what you call a module, how large a module is and how the organizational situation looks like. For example, lets say the "shared lib" is the whole "Python" stack, and the two shared libs are "Python 2" and "Python 3" (which has become famous for not being really backwards compatible". In case you are managing a larger application with two huge "modules", one base on Python 2 and one on Python 3 ...
    – Doc Brown
    Commented Aug 9, 2021 at 9:47
  • 1
    ... and each of the modules is large enough to be maintained by two different sub-teams, updating the module based on Python 2 two 3 may not be economically, but freezing the development of one modules may not be possible through contractual bindings.
    – Doc Brown
    Commented Aug 9, 2021 at 9:50
  • 1
    ... if, however, the shared lib is something not too complicated under your teams control as well as all the 100 modules using it, and you have some powerful refactoring tools as well as automated tests, even a non-backwards compatible API change may not be painful.
    – Doc Brown
    Commented Aug 9, 2021 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.