What is semantic versioning and does it also work for systems?
In the 2000s, developers dreamed of software components that developers would assemble like Lego bricks. This is now a reality. This is made possible by a rich ecosystem of extremely user-friendly, generally free tools.
However, one of the reasons why this ecosystem works is because the software components are versioned semantically. What exactly semantic versioning is, and why we still don't have it in systems engineering, is the subject of this article.
Semantic versioning
Semantic versioning (SemVer) solves the problem of resolving dependencies between software components. It therefore refers to "units" whose dependencies need to be managed. This can be the software itself, but it can also be parts of the software (i.e. software components). However, interfaces (APIs) and specifications also generally require versioning.
Semantic Versioning 2.0.0 & FAQ
Semantic versioning is based on three numbers separated by dots: MAJOR.MINOR.PATCH (e.g. 16.1.25). Each of these numbers has a specific meaning:
- MAJORChanges that are incompatible with previous versions.
- MINOR: Additions of functionalities that are downward compatible.
- PATCH: Bug fixes and other minor changes that do not add new features and remain compatible.
Advantages of semantic versioning
The aim of semantic versioning is to ensure clear and comprehensible communication about changes to software. Developers can use the version number to immediately recognize whether an update involves risks or can simply be installed. Semantic versioning is very easy to understand and also makes intuitive sense. It is therefore an excellent communication tool.
Semantic versioning makes intuitive sense and improves communication.
For the developers, it is clear that a leap in the Major version requires reworking and should therefore only be carried out with good reason. In contrast to this Patches be incorporated quickly. This is because patches should not change any functionalities. Patch releases mainly consist of bug fixes and closing security gaps.
Minor versions bring the best of both worlds. As a rule, these can be used without hesitation as they are backwards compatible. At the same time, they bring new features. For example, a library for image processing could support a new image format. This does not change the existing functions.
Process semantic versioning automatically
However, SemVer becomes really powerful through the automatic management of dependencies. By now, every serious programming ecosystem has a component system that uses semantic versioning. I already had experience in the early 2000s with OSGi the component model, which was developed by Eclipse is used.
In a typical development project, we record the dependencies of our software in a configuration file. If you work with Node.js, you would do this in the package.json file. Here is a small example that shows the essential aspects of semantic versioning. The prefix in front of the number defines its meaning:
{
"dependencies": {
"typical-package": "^1.4.0"
"fix-minor-package": "~1.4.0"
"flexible-package": ">=1.0.0 <3.0.0"
}
}- typical-package (^): Everything in this major version from 1.4.0 is allowed, i.e. 1.4.0, 1.4.2, 1.5.3. Everything before 1.4.0 and everything from 2.0.0 is forbidden. This is the most common case in practice.
- fix-minor-package (~): We can also be stricter and ban other major versions. In this example, 1.5.0 and better is prohibited.
- flexible-package (>, = <): Using the usual mathematical operators, we can set virtually any desired version range.
Of course, each of the packages listed has its own dependencies, so that a large tree of
Modern applications often contain hundreds of packages, which can lead to problems with dependencies. For example, if two components use the same component for logging, then a version must be found that is suitable for both projects.
So if one requires ^1.4.0 and the other ~1.5.2, then a version must be selected that fulfills both conditions. In order to find a suitable configuration here, all constraints must be taken into account. A Constraint Solver then finds a suitable configuration.
Incidentally, the success of package management is also the reason why the log4j disaster The majority of programs had only integrated the component indirectly via dependencies, as can be seen in the following image:
Conversely, the vulnerability could also be permanently closed in this way: as soon as a developer had banned the affected version via semantic versioning, the constraint solver ensured that no installed package used this package.
Semantic versioning in systems engineering
In contrast to software development, systems engineering is an area that often combines physical and digital components. Despite the increasing proportion of software in such systems, the idea of uniform semantic versioning remains difficult to implement. Why?
Complexity of dependencies - A software project can define dependencies to other packages relatively easily. A system, on the other hand, often consists of a multitude of building blocks: mechanics, electronics, software and other components that interact with each other. A small change to one part of the system could have unexpected effects on other parts.
Lack of standards - While SemVer is well established in the software world, there is no comparable, widespread practice in systems engineering. In software development, there is a rich, often free range of tools, frameworks, libraries and much more. In systems engineering, we are miles away from this.
Long development cycles -Short release cycles are common in software development. New features or bug fixes are often released within weeks or even days. In systems engineering, on the other hand, development cycles can take years. Standardized versioning might seem less effective here, as changes occur less frequently. However, what I see as a misconception, and some companies work with 2-day release cycles for complex products such as rocket engines.
Different life cycles - A software package can be updated regularly, often without physical restrictions. Physical systems, on the other hand, have life cycles that depend on maintenance, availability of spare parts and regulatory requirements. Versioning would have to take these factors into account. Therefore, I have long stated that these cycles need to be loosely coupled (which works well with SemVer)
A way forward: automation and interface versioning
We will certainly not be able to implement semantic versioning in systems engineering in one fell swoop. I see two points in particular where we can start.
For one thing, we inevitably need to automate more. Effective automation requires proper versioning (at least if we don't want to duplicate tasks, even automated ones). Semantic versioning supports automation because it can be used to automatically identify obsolete artifacts. The Change management is automated.
I also recommend starting with the interfaces. If we try to record the interfaces in a semantically clean way, this process will also sharpen the quality of the interfaces and reduce problems during integration. Here is an example:
USB: Versioning of hardware, electronics and software interface
The USB standard is a good example of complex versioning that covers several levels. On the mechanical level different connector types such as USB-A, USB-B, Micro-USB, USB-C or Mini-USB are specified. Changes to the mechanical specification are often introduced with new major versions of the standard, such as the change to USB-C, which not only brought a new connector design, but also created the basis for many other improvements.
On the electrical level is about voltages, signals and charging currents, such as those used with USB Power Delivery (USB PD).
On the software level These protocols determine the speed and functionality of data transmission and are based on the respective mechanical and electrical standards. USB 3.0, for example, enables a significantly higher transmission speed than USB 2.0, but remains partially downward compatible. This multi-layered versioning ensures a clear separation of responsibilities and a gradual introduction of new technologies without immediately rendering existing systems obsolete.
Conclusion: SemVer as inspiration for systems
Semantic versioning has revolutionized software development and enabled an entire ecosystem of modern tools. It could bring similar benefits to systems engineering.
Even if systems engineering is still a long way from being as advanced as software development, we can still use semantic versioning in many places where simple version identifiers were used in the past. The versioning of interfaces is at the top of the list.
So the question is not, whether semantic versioning works for systems, but like it can best be implemented.
