An Argument for Semantic Versioning in Mechanical Design

12th February 2024
5 min read

I've worked at and worked with many different companies over the years.

They all do versioning differently:

  • A, B, C… for major and minor releases.
  • 1, 2, 3… for minor releases, then a switch to A, B, C… for major releases.
  • P1, P2, P3… then drop the P prefix restart at 1 for major releases.
  • 1a, 1b, 2a… etc etc

The list goes on.

At some point in time somebody within each and every company has decided to use a specific system. Sometimes by default; falling back to alpha or numerical characters and running with it. Sometimes even improving the versioning system by mixing and matching alphanumeric characters.

Sometimes even implementing an intelligent system that meant something at some point, but everyone that uses the system has either forgotten what it means or doesn't know. To anyone outside the company it's just a meaningless character string, assumed to increment up.

Worse, if the system switches characters between version types, it can quite literally confuse the issue. Is 1 a newer version than A?

Sure, letters and numbers are pretty standard, but they are not standard.

Despite mechanical engineering having been around since at least 1847, it's taken the thoroughly wet-behind-the-ears industry of software engineering to figure it out.


The answer might be Semantic Versioning.

Even if you're not a software developer, you've no doubt seen the x.y.z versioning system used for many different bits of software.

Quite simply it's: MAJOR.MINOR.PATCH.

Each element is a non-negative numeral (say that three times fast!), that increments sequentially.

That's it.

And there's no reason at all it can't apply to mechanical design.

Semver in Mechanical Design

Using Semantic Versioning for mechanical design is equally straight-forward, and can be used essentially verbatim (as long as you can tolerate the term "patch"). It's not harder to use over more archaic systems, and provides additional meaningful functionality.

The major and minor versions operate as you would expect. It also allows the correction of errors to be captured and communicated - something wholly missing from versioning systems used in mechanical design today.

Here's the cheat sheet:

Development EventVersion ChangeRuleExample
Pre-release developmentMinor versionIncrement minor version and reset patch version0.1.0
First releaseMajor versionIncrement major version and reset minor and patch versions1.0.0
Error correction without design changePatchIncrement patch version1.0.1
Minor improvement that doesn't break compatibility/dependencyMinor versionIncrement minor version and reset patch version1.1.0
Major architecture change or breaks compatibility/dependencyMajor versionIncrement major version and reset minor and patch versions2.0.0

Major Version

Semver works the same way as any other system: up-rev the major version when anything, well, major happens. This may be a significant system architecture change, or more importantly, when you break compatibility with interfacing devices*.

Major version zero (0.y.z) is used for development up until initial release. "ZeroVer" is treated a little bit differently, in that all bets are off on whether a change maintains compatibility or not. This does however provide an ideal environment for rapid development, without compromising traceability of changes. Once any product is ready for release, it's reviewed, approved, and published at a crisp version 1.0.0.

Minor Version

The simplest versioning systems either don't track development revisions at all, which it risky, or their first major release is Rev K. I'm sure this is why some systems use different types of characters for development and release versions, however a limitation of systems that switch nomenclature after initial development is you can't go back. And you can't tell me you've never needed to make a change after release.

Using a dedicated minor version digit in mechanical design is highly valuable in being able to track changes to draft versions prior to release. More than that, it can track development of updated designs after release.

Minor versions work the same as major versions, but for changes that don't break compatibility between interfacing devices.


Regardless of the name, its function is for error correction. A patch increment denotes a change to correct an error in either the drawing or model, without any change to the design. As for why this matters, read on.

Why It Matters

Mechanical design is historically insular. Quite possibly the lack of harmonised versioning industry-wide is because, unlike the software industry, there has been little need for interoperability between companies and systems. Products are designed in-house, turned into product in-house, and then shipped. Outside of the company who cares what the versioning system looks like? Nobody will see it.

Yet, even for companies that design in-house and have a supplier produce goods for them, there can be value in clearly communicating versions. In a past life I worked with a supplier that wanted to be able to easily identify when a drawing change was for error correction only. In this situation we added a different number entirely to denote corrections. We essentially had two simultaneous and independent version systems on the one drawing. Semver would have been more streamlined than what we ended up with.

For [Industrial Design] consultancies it can make even more sense to adopt Semver. Their work is inherently interoperable and often tech-oriented. Easy to understand and interpret versioning can make much more sense for both clients and other collaborators (especially software devs).

Using a standardised versioning system means others know what kind of changes have happened just by looking at the version number. It's clear what to look for and what the scale of impact is.

The Argument

I've been using Semver for several years.

You may argue that this is a much more complicated system than simply using A, B, C or 1, 2, 3. And you'd generally be right, for things that are simple.

However product development, especially medical device development, is anything but simple. When there are many moving parts across many disciplines and collaborators, it makes sense to standardise versioning too.

Of course, there's always good reasons why Semver doesn't work for every situation. If you've got any, I'd love to hear them.

* In this regard Semver is of particular benefit in orthopaedic device development. Specifically for instrumentation. When instrument sets get large with many interconnected components, like total knee, being able to denote when a combability change has taken place is important.

I post every week on the topics of design, medtech, and my journey in it. If you'd like to follow along, feel free to subscribe to the newsletter, follow on LinkedIn, or subscribe to the RSS feed with this link.

Tagged: business · consulting · design · design studio

ⓒ Lincoln Black 2024

Get some free design thinking, fresh every week. Straight to your inbox.

I respect your privacy and will only send you the fresh design thinking you've asked for.


Virtimachi Pty Ltd

ABN 31 651 760 762

PO Box 7156 Kariong

NSW 2250 Australia