Versioning – Should All Component Version Numbers Always Be the Same?

versioning

We are planning to use a setup that uses several modules to complete a whole application, example modules include:

  • The core (code shared by all other modules)
  • The server
  • The client (Windows, OS X, Linux)
  • The client (iOS)
  • The client (Android)
  • Tool #1
  • Tool #2

And now while we preparing to deliver our first release, it is a good time to think about the numbering scheme. We have defined to use a major.minor.patch format, but we are struggling about one question:

Should every module have the same version number as newest release, and consequently, should we bump version numbers if there has been no update to them?

Example to illustrate:

1) Assume all our components are running on version 0.1.0 (early development), once we do a significant update, should then all components be bumped to version 0.2.0?

It also works the other way around:

2) Assume again every component is running 0.1.0 initially, and now we introduce a signifcant update (could be a GUI rework) on the Android client, should we then release a version 0.2.0 for every component, even though the other versions have not received any update?

And perhaps the most tricky one:

3) Assume that we still run 0.1.0 one very component in the start, and we figure out Tool #2 has a bug and we need to hotfix it to 0.1.1, should we also then update every component to 0.1.1?

I am currently doubting whether we should pursue correct versioning, or should go for compatability? People outside to the development team will most likely expect that all modules run on version 0.3.0 for example, while we as developers are a bit confused and perhaps feel uneasy with bumping a version number up, while the module did not have any change to it.

What is the best way to deal with this?

Edit, something I have forgot to mention, but which may change opinions is that all releases will be done in automated way. On Github/git a specific commit will be tagged being version major.minor.patch and after that the build system (here: Travis CI) will pick up the tag and automatically build every release and publish it somewhere if necessary and/or wanted.

Best Answer

First off, there is no correct way.

However, I have found that keeping all version numbers the same across releases, regardless of whether things have changed or not, makes things much easier down the road. If I want to know what has been going on in a software, all I want is to be able to easily go from a version number to a state in version control, and see whats going on in there. Having a collection of unrelated version numbers makes doing that murky.

The alternative is that ultimately you have to maintain some sort of BOM for your software releases to know what's what, and those invariable end up out of date or incorrect, and everything just becomes a big mess.

There have been situations I've worked on where products did have a mismatch of version numbers for various dlls. It was a medical device software, and the developers rationalized that by not changing certain parts, they could avoid doing testing and verification for those parts. It may have saved work there, but it has created plenty of other work and harmed credibility with distributors when even the company wasn't sure what was what because of the hard to understand versioning scheme.

Related Topic