Software versioning in large-scale systems

Question

My company is developing a system for 10 years. This system has 15 subsystems that are almost independent (they may use same libraries or packages or DBs), and these subsystems are building locally in separate teams, also a main simple system is developed to read subsystem configs and build a page with menu and submenu from configs(with shortcuts). Our company's product is the exe of this main system.

Unfortunately, we do not use a standard version numbers in our company. Now, we decided to force a standard in company, and I found Semantic Versioning a satisfactory standard, but I have some questions in our case: How would the changes on subsystem version increase the main system version? Often, after even Major changes in a subsystem, the code of main system remains unaffected. I think changes in the main system should shape the version number of that system, but in this case it does not make sense. Is there any solution for versioning of large applications that consist of multiple subsystems?

Answer 1

I think you're on the right track for this - literally treat everything with a SemVer version as it's own thing.

If you need to rebuild an updated linked dependency then at the least it'd be a patch version update - if they're simply soft links (ie, someone can update the subsystem without rebuilding or needing fixes) then it's purely a case of wanting a version number of when it was changed.

Keeping to the SemVer idea, if things cause incompatible changes then pulling the highest change out could make sense. Ie - updating 5 subsystems at the same time, 4 are patch updates, and one a minor - you'd update the minor version of the main system only (and put them all into that single change). Same with major changes etc.

The other similar idea is to drop the changes slightly if the main build is purely an interface on top - any minor or patch changes would only cause a minor on it, and any major subsystem changes would cause a minor - that way you can keep the major for breaking front end changes etc.

Something to bear in mind is that you don't have to follow SemVer perfectly - consistency is the key for something like this - so you could update the patch level for when subsystem changes are merged in, and never reset it, while updating the minor and major versions only for the main system. (There are a couple of open source projects that work this way, I just can't remember which ones off the top of my head).

Not sure if it's any use, but you could look at some of the nodejs packages around and how they update their versions with differing dependency versions - they all include a list of what they use in a package.json file with the version listed in a certain format (ie, exactly x.y.z or >x.y.z etc - https://docs.npmjs.com/files/package.json#dependencies)

Answer 2

From the SemVer FAQ:

What should I do if I update my own dependencies without changing the public API?

That would be considered compatible since it does not affect the public API. Software that explicitly depends on the same dependencies as your package should have their own dependency specifications and the author will notice any conflicts. Determining whether the change is a patch level or minor level modification depends on whether you updated your dependencies in order to fix a bug or introduce new functionality. I would usually expect additional code for the latter instance, in which case it's obviously a minor level increment.

I would apply this to your scenario as follows: If your main application takes upgrades of its dependent subsystems without having to make major changes in itself, it should increase either the minor or the patch version. You shouldn't need to increment the major version, as its own public API is still considered compatible.

If the main application makes use of new features added to the subsystems, it should be a minor version increase.

Otherwise, it should be a patch version increase.

Answer 3

You gave a link to MAJOR.MINOR.PATCH, and increment the
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner,
PATCH version when you make backwards-compatible bug fixes
Any change in a subsystem might make the main system incompatable: Too much to keep track of.
Each subsystem should use their own version. In the main system you should have an overview of the dependencies and the own versioning.
You can manage this in different ways. One way would be using Maven and pom.xml files. Another way would be using a config file with the different versions.
Each team can develop their own code independent and assign Semantic versions.
Maybe some day you will put the shared libraries, packages and DBs in a repository and all teams can refer to them with their own pom.xml.
You are flexible this way. You might even want to make a second main system (for top clients or for free accounts?) and can change the pom.xml including/excluding subsystems. The second main system will have its own versioning.