What Does 0.1.0 Mean? Software Versioning Standards: SemVer, CalVer, and ZeroVer Explained

When you open a package.json, Cargo.toml, or pyproject.toml file and see version numbers like 1.4.2, 0.1.0, or 24.04, it is easy to treat them as arbitrary labels picked by the maintainer.

In reality, a version number is a formal engineering contract between the author of a library and every production system that depends on it. Misunderstanding that contract is one of the fastest ways to bring down a live application with a single npm update.

Let's break down the four dominant versioning philosophies used across modern software engineering.

1. SemVer (Semantic Versioning): MAJOR.MINOR.PATCH

Created by Tom Preston-Werner (co-founder of GitHub) and formalized under the SemVer 2.0.0 specification, Semantic Versioning is used by roughly 90% of open-source libraries.

Every release follows a strict three-part format: MAJOR.MINOR.PATCH (for example, 2.4.1).

   2   .   4   .   1
   │       │       └── PATCH: Backward-compatible bug fixes & security patches
   │       └────────── MINOR: Backward-compatible new features
   └────────────────── MAJOR: Breaking changes (Incompatible API modifications)

How Each Increment Works

• PATCH (2.4.1 ➔ 2.4.2): Only internal bug fixes, performance tweaks, or security patches. No new public methods are added, and existing code is guaranteed not to break.
• MINOR (2.4.2 ➔ 2.5.0): Adds new functionality in a backward-compatible manner (or marks an old method as @deprecated without removing it). Note that bumping MINOR resets the PATCH counter to 0.
• MAJOR (2.5.0 ➔ 3.0.0): Indicates a Breaking Change. Function signatures changed, parameters were removed, or return types were altered. Upgrading across a MAJOR version requires reading the migration guide and updating your application code.

2. ZeroVer (0.x.x): The Eternal Beta Warning

What does 0.1.0 or 0.24.3 actually mean?

According to Rule 4 of the official SemVer 2.0.0 specification:

"Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable."

In a 0.x.x library (often playfully called ZeroVer), the standard rules are shifted by one position in practice: maintainers frequently introduce breaking changes inside a 0.1.0 ➔ 0.2.0 minor bump.

3. CalVer (Calendar Versioning): Time-Driven Releases

Not every project fits cleanly into SemVer. Operating systems, browsers, and large developer platforms evolve continuously rather than revolving around a single API contract. These projects use CalVer (YYYY.MM or YY.0M.MICRO).

• Ubuntu Linux: 24.04 LTS literally means April 2024. You immediately know when the OS was released and when its 5-year support window expires.
• JetBrains IDEs: 2026.2 means the second major release of the year 2026.
• pip & Certbot: Use YY.M calendar releases to signal how old a deployment tool is at a glance.

4. Git Commit SHA Versioning (CI/CD & Microservices)

If you are building an internal web application or microservice deployed 15 times a day via GitHub Actions, manually bumping 1.0.14 to 1.0.15 is pointless bureaucracy.

Modern DevOps pipelines tag Docker images and Sentry releases directly with the immutable Git Commit Short SHA or a timestamped hybrid:

# Tagging a production container image with Date + Git Commit SHA
GIT_SHA=$(git rev-parse --short HEAD)
IMAGE_TAG="2026.10.25-${GIT_SHA}"
docker build -t registry.czay.dev/api:${IMAGE_TAG} .

When an exception fires in production at 03:00 AM, you don't have to guess what v1.4.9 maps to—you run git show a4b8c1f and see the exact commit immediately.

Summary Decision Matrix