How software is versioned

Three numbers, and mostly the way SemVer spells them

Of the versions this catalog can read as numbers, 85.2% are three components long, and 81.2% are strings SemVer 2.0.0 would accept as they stand: three integers, no leading zero, an optional tail. Counted per product instead, so that a project tagging nightly counts once, the SemVer-shaped share is 82.5%. Whatever vendors say about their versioning policy, this is the spelling they have settled on. 15.9% of the SemVer-shaped strings carry a prerelease or build tail; the rest are the bare three numbers.

Every version string in the catalog, by the grammar it is written in. Releases are a share of all versioned releases; products are the vendors whose releases are mostly written this way, of those with at least 5 the reader recognizes. Examples are the newest releases in each bucket and link to the release counted.

• SemVer-shaped

  74.2%of releases · 19,898|82.5%of products · 1,031

  Three integers with no leading zero, then at most a -prerelease and a +build tail. Exactly what SemVer 2.0.0 would accept.

  • v4.1.5Argo Workflows
  • v3.20.242-ltsToolJet
  • v3.27.0OpenAI Python SDK
  • 12.1.4Avalonia
  • v5.3.0express

• Plain numbers

  12.9%of releases · 3,449|9.0%of products · 112

  Dotted integers, but not three of them, or one of them carries a leading zero SemVer forbids.

  • v2026.10.09.4Gumroad
  • v0.102.2814.0PowerToys
  • 15.0.245.54v8
  • 2026.10Overcast
  • 2126.2Azahar

• Number plus a suffix

  4.3%of releases · 1,147|2.6%of products · 33

  A numeric core with a tail SemVer has no grammar for: a glued b5 or esr, a fourth component followed by more.

  • v26.8.22.13-ltsClickHouse
  • 15.0.245.54-pgov8
  • 2026.10.0b2ESPHome
  • 1.8.0-rc.1791509415276Radix Primitives
  • 6.0.0-b5.20261008180624Matomo

• Not a number at all

  8.7%of releases · 2,338|4.9%of products · 61

  A string the version reader declines because it leads with a word, a package name or a date rather than a number.

  • Pre-release-shadPS4-2026-10-09-0c9ca525b8add53e62b3ccd9c9c2f6ef2ebabbfashadPS4
  • develop-20261009.3Firefly III
  • release_v3.11pycparser
  • formatjs_cli_v1.8.1formatjs
  • openssl-4.1.0-beta2OpenSSL

SemVer-shaped is a fact about the string, not about the project. A build number written as three dot-separated integers passes the same test as a library that documents every breaking change, and the two are counted together here because the corpus cannot tell them apart.

The channel is a grammar of its own

Where a release is published decides much of how its version is written, because most channels have rules of their own. Package registries validate a version before they accept it, and they sit at 96.1% SemVer-shaped; releases tagged on GitHub, where the string is whatever the maintainer typed, sit at 86.1%. At the other end, Steam publishes patch notes with no version field at all: 100.0% of the releases tracked from it carry none. A vendor blog sits in between: a headline names a version when the writer chose to put one in it, and 57.2% of the releases read from feeds did not.

By category the spread runs from AI at 98.5% to Games at 10.4%. Underneath the ranking, developer-facing software clusters at the top and the categories where a version is printed for an end user rather than parsed by a tool sit lower. A two-part browser version or a four-part build is a perfectly good version; SemVer simply has no grammar for it. One category barely versions at all: Games publishes 93.3% of its releases with no version.

The v is a GitHub habit

Whether a version starts with a v gets argued about more than it matters. Across the catalog, 51.6% of readable version strings open with one, and 53.7% of products write it more often than not. That is two populations averaged together, not a field of undecided vendors. On GitHub, where the version is the tag the maintainer pushed, 69.9% lead with a v. On nine channels — registry, sparkle, appstore, scrape, jetbrains, versions, play, adobe and riot — not a single version does. Some of those are stores and registries that normalize the string before anyone reads it. The rest are vendors’ own release-notes pages, where the number is written into prose and nobody types a v.

The v is a property of Git tags more than a convention. It appears where the tag is the version and disappears wherever a platform sits between the maintainer and the reader.

About one version in 12 is a date

Calendar versioning has its advocates, and it is visible here without being common: 8.3% of readable versions, from 78 products, either open with a four-digit year or carry a zero-padded component like .09 that only a month explains. 1,534 do the first and 1,231 the second, with some doing both. That figure is a floor: a two-digit year with no padding, like 26.2, cannot be told from a major version in the twenties, so those are counted as plain numbers and the true share is somewhat higher.

• v2026.10.09.4Gumroad
• v2026.10.6mise
• v2026.10.9-canary.912AFFiNE
• 2026.10.0b2ESPHome
• 2026.10Overcast

When the tag is a name

8.7% of the version strings vendors publish are not numbers at all by the reading used here, and 61 products write most of theirs this way. The examples show the shapes: a rolling nightly or preview tag with no number in it, a package name in front of the number because the repository holds several, a branch, a channel or a language in front of it, a date with a commit hash. Each one is a version to the people who wrote it and a name to any tool that has to sort it.

• Pre-release-shadPS4-2026-10-09-0c9ca525b8add53e62b3ccd9c9c2f6ef2ebabbfashadPS4
• develop-20261009.3Firefly III
• release_v3.11pycparser
• formatjs_cli_v1.8.1formatjs
• openssl-4.1.0-beta2OpenSSL

They are counted and left in the denominators on purpose. A report that dropped whatever its reader could not parse would be measuring the reader rather than the vendors.