Lite Versioning

Summary

A version number takes the form MAJOR.MINOR:

  2   .   7
  │       │
  │       └─ MINOR  bumped on every release that won't break you   (safe)
  └───────── MAJOR  bumped when a release will break you           (look first)

• MAJOR: bump it when a release is not backward compatible, so the people and software depending on you may have to change something to take it. Resets MINOR to 0. 0 is reserved for initial development; ship your first stable release as 1.0 and go from there.
• MINOR: bump it for every other release: new features, bug fixes, performance work, deprecations, anything that keeps the contract. Safe to take without looking.

Where a tool insists on three numbers, write 2.7.0. The trailing 0 is padding: always 0, never bumped.

Introduction

Semantic Versioning asks three questions of every release: did it break the contract, did it add something, or did it only fix something? The people who depend on you act on the first answer and mostly ignore the other two.

Look at how SemVer versions are consumed. npm saves ^1.4.2 by default, which takes every MINOR and PATCH release automatically. A Cargo requirement of "1.4" does the same, and so does Ruby's ~> 1.4. The difference between a feature and a fix is worked out carefully by the publisher, then thrown away by almost every consumer.

It isn't free to work out, either. Every release starts with a small debate: is this a feature or a fix? Does a bug fix that adds an option count as a feature? Commit conventions, changelog tooling, and release bots exist largely to settle it.

LiteVer keeps the promise people rely on and drops the one they don't. A version is MAJOR.MINOR: a MAJOR bump tells you to look before you upgrade; a MINOR bump tells you that you don't have to.

LiteVer deliberately says nothing about the size of a change. A one-line fix and a big new feature both bump MINOR by one, because neither breaks anything. A tiny removal bumps MAJOR, because it does.

LiteVer Specification

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are to be interpreted as described in RFC 2119.

1. A project using LiteVer MUST declare what it promises to the people and software that depend on it: its public API, interface, or documented behaviour. This is the contract. It SHOULD be precise and comprehensive, whether it lives in code or in documentation.
2. A normal version number MUST take the form X.Y, where X (MAJOR) and Y (MINOR) are non-negative integers and MUST NOT contain leading zeroes. They are two separate integers, not a decimal: 1.10 comes after 1.9. Each successive release MUST increase in precedence, as defined in rule 7.
3. Once a version has been released, its contents MUST NOT change. Any change MUST be released as a new version.
4. MAJOR 0 is for initial development. Anything MAY change at any time, and the contract SHOULD NOT be considered stable. Every 0.Y release MAY be breaking.
5. MAJOR (X) MUST be incremented when a release makes any backward-incompatible change to the contract. It MAY also be incremented without one, but consumers will treat every MAJOR bump as breaking. When MAJOR is incremented, MINOR MUST be reset to 0.
6. MINOR (Y) MUST be incremented for every release that keeps the contract backward compatible: new features, bug fixes, deprecations, performance work, internal changes, and anything else. LiteVer draws no distinction between a feature and a fix.
7. Precedence is determined by comparing MAJOR, then MINOR, numerically (0.9 < 1.0 < 1.9 < 1.10 < 2.0).
8. Padding. The canonical form has two components. Where a tool, registry, or ecosystem requires three, a version MUST be written as X.Y.0. The third component is padding: it MUST always be 0, MUST NOT be incremented, and carries no meaning. X.Y and X.Y.0 denote the same version. A project SHOULD use one written form per ecosystem, consistently.
9. Identifiers MAY be appended: a hyphen introduces pre-release identifiers (e.g. 2.0-rc.1, padded 2.0.0-rc.1) and a plus sign introduces build metadata (e.g. 2.0+20261019). Their syntax and precedence follow SemVer 2.0.0: a pre-release version has lower precedence than its normal version, and build metadata MUST be ignored when determining precedence.
10. One line per MAJOR. Within a MAJOR version, releases form a single sequence. A fix for an older MAJOR line is released as the next MINOR on that line (with 2.x current and 1.9 the latest 1.x, a backported fix ships as 1.10). Earlier MINOR versions within a line are not maintained separately, because every later MINOR in the same line is a compatible upgrade.
11. Initial version and going stable. A project SHOULD begin at 0.1. Version 1.0 defines the first stable contract; a project SHOULD release it once its contract is stable, or as soon as others depend on it in production, whichever comes first.
12. Scope. LiteVer is for anything that offers a contract to others and whose consumers need one answer from a version number: can I take this without changing anything? That includes libraries, packages, APIs, command-line tools, plugins, file formats, and specifications.

Why use LiteVer

• One question, one number. 2.7 → 2.8 is safe to take. 2.8 → 3.0 means read the notes first. The version answers the only question a consumer acts on.
• It ends the feature-or-fix argument. No more debating whether a fix that adds an option "deserves" a MINOR or a PATCH. If it doesn't break anything, it's MINOR.
• It speaks your tools' language. Padded to X.Y.0, a LiteVer version is a valid SemVer string. Caret ranges, Cargo requirements, Ruby's ~>, and sort orders all work unchanged. Your consumers don't need to know you use LiteVer.
• It's how people already talk. Nobody says "we're on two point seven point three". They say "we're on 2.7". LiteVer just makes that the whole version.
• Easy in, easy out. Moving from SemVer needs no renumbering, and moving back is just as easy (see the FAQ).

When NOT to use LiteVer

LiteVer trades away SemVer's feature/fix distinction on purpose. It is the wrong tool when:

• Your consumers rely on patch-only updates. If downstream users (long-term support distributions, regulated environments, slow-moving enterprise deployments) need to take fixes without taking features, they need SemVer's PATCH line (~1.4.2). LiteVer gives that up.
• You maintain several MINOR lines at once. If you support 2.3 and 2.4 side by side with separate fixes, you need a third number to tell them apart.
• Your app ships through a native and an over-the-air channel. For a React Native or Expo app, the useful question is how a release reaches users, not whether a contract broke. Use PaceVer.
• Your audience keys off recency. If readers of your version number mostly want "how recent", use CalVer.

Adopting LiteVer means giving up patch-only update ranges in exchange for a simpler number and a simpler release process. Make that trade on purpose.

Example: one library's version history

Every row answers "can I take this without looking?" from the number alone: a MINOR change means yes; a MAJOR change means read the notes first.

Writing LiteVer in your ecosystem

FAQ

About

LiteVer was created in 2026 by Pavlos Vinieratos. It is a sibling of PaceVer, which versions apps by the pace each release travels at.

This specification is versioned with LiteVer itself.

Current version: 1.0 (LiteVer).

License

LiteVer, the Lite Versioning specification, is licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). You are free to share and adapt it, including commercially, as long as you give appropriate credit.

Copyright © 2026 Pavlos Vinieratos.