Software Versioning Basics

1. What happens when you skip versioning

When you build or maintain an app, new features ship, bugs get fixed, and behavior keeps changing. It can feel pointless to tag every pushed change with a version — right now it's obvious what the app does and how it works.

But you need to think ahead. You can orient yourself by installation date, but that's a vague reference point for traceability, since it may or may not match the actual release date.

2. What you get from versioning properly

A version number is a shared reference between development, support and the customer. Once someone reports a version number, everyone involved knows exactly what state of the app they're talking about.

Version correctly, and you can easily look up what changed in which version, when it was released, where it's installed, and whether it's safe to roll back from.

3. Which versioning schemes exist

Semantic versioning, or SemVer, uses three numbers — MAJOR.MINOR.PATCH. You bump major on a breaking change, minor on a new feature, and patch on a fix. It fits anywhere compatibility matters, typically libraries and public APIs.

Calendar versioning, or CalVer, encodes the release date into the version itself, e.g. 2026.08 or 2026.08.2. It suits apps with a regular release cadence, where the customer doesn't care about compatibility, just how old the version is.

The simplest option is to use a build number or a plain sequence that just keeps increasing with every release. That's usually enough for internal tools and automated builds, though for a human it's an anonymous label — it reveals neither the release date nor any breaking changes.

Combinations of these schemes are common too — SemVer with a release date in the description, or CalVer with a build number. Versions are also often prefixed with a letter, like v1.2.3 or 2026.08.2b, and can carry extra information, such as the development stage (alpha, beta, rc) or the platform (android, ios).

4. What you actually need for this kind of versioning

If your source code lives on GitHub, GitLab or Bitbucket, you can use their built-in version-tagging tools. On GitHub that's Tags, which attach a version to a specific commit.

For every version, it's worth keeping a changelog — a readable list of changes for humans (or AI), separate from the raw commit history. It can be a plain text file, though there are also tools that generate a changelog straight from commits.

5. When versioning without automation is enough

Not every product needs CI/CD-driven versioning. Simple products, or apps released on a long regular cadence (say, monthly, twice a year, or yearly), often do fine with writing down the version by hand at the moment you actually ship it.

In aboutthe.app, you can keep a version history for exactly this kind of product the same way — add a version number and its changes by hand. The version overview and its changes are then available to everyone with access to the product.