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

TomatenSalat
  • 732
  • 1
  • 5
  • 9
  • 1
    Can't you use the same version of the library for all modules without always using the latest? – Ben Cottrell Aug 06 '21 at 16:35
  • 2
    2 is the only one that actually works if you have breaking changes – Ewan Aug 06 '21 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 Aug 06 '21 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 Aug 09 '21 at 09: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 Aug 09 '21 at 09:29
  • @ThomasOwens at the moment they are libraries but could be separated into many different executables. At the moment they are distributed to together but maybe having an installer that only updates certain parts would be a benefit of #2 – TomatenSalat Aug 09 '21 at 09:30
  • @TomatenSalat Are the bug fixes always urgent (and if its urgent, wouldn't it be urgent for all the modules)?. What if there's a new version which doesn't have something you need, couldn't you just defer updating? - i.e. How often do you really gain any benefit from updating, and how often can you simply defer the update until a later date? (So that you can reduce the frequency of updates down to only the bare minimum necessary) – Ben Cottrell Aug 09 '21 at 11:16
  • @TomatenSalat you cant adapt a previously released version, you could release a v1.1 and update the versioned used on all the clients, but then you might as well upgrade to the latest – Ewan Aug 09 '21 at 12:03
  • Option 2 may have issues if the modules need to share types defined in the shared library. Jon Skeet has an article on [Options for .NET’s versioning issues](https://codeblog.jonskeet.uk/category/versioning/) that may be relevant. – JonasH Aug 15 '22 at 12:45

1 Answers1

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • 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 Aug 09 '21 at 09:37
  • 1
    @TomatenSalat: maybe you can start by putting your question into a context first? – Doc Brown Aug 09 '21 at 09: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 Aug 09 '21 at 09: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 Aug 09 '21 at 09: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 Aug 09 '21 at 09:54