Yesterday I talked about three reasons we use versions in our software.

Now I’m going to try to convince you that you may not even need version numbers at all! Or more accurately, that you can just use your version control commit ID as a version number.

Why would you even want this? Well, simply put: Managing version numbers can be a pain. In the simplest case, a version number usually corresponds to a tag in a git repository. That tag has to be created and managed somehow.

In more complicated cases, a version may need to live in actual files in a repository. A simple example can be the package.json file found in most JavaScript packages. Updating this automatically is a major pain, as it requires actually adding commits to the repository, which is widely considered bad practice.

So when can you skip this toil? There are basically two rules I use:

1. The software represents some sort of end-product. That is to say, it’s not a shared-library, and doesn’t need to be a versioned dependency of any other software.

   A monolithic web app, a single microservice, or a mobile/desktop app are typical examples of this.

2. No end-user ever needs to read the version number. By end user, I mean someone not working at your company.

   Web apps and microservices are good examples. Mobile and desktop apps probably are not.

If your project meets these rules, you have a good candidate for simply using the VCS commit ID for your versions. This is because the only thing you need a version number for is to identify which build of your software produced some behavior (probably a bug, or an error log). For this, version dfc8a9a3 is just as good as version 1.3.6.

Of course, some build systems require a version of a specific format. For example, package.json, used in JavaScript projects, uses semantic versioning. But if no other software depends on your package as a dependency, nothing will ever actually care about this version number. Set it to some token value, like 1.0.0, then ignore it!