(release, major, minor) is honestly how versions often get used in the wild. Especially in CD contexts where every change is versioned and deployed and the meaning between patch and minor gets a little lost.

I would still like this proposal to formalise having an optional PATCH in there though:

    BIGRELEASE.MAJOR.MINOR[.PATCH]

That way one can lock the version to get only actual bugfixes, with no other change:

    gem 'foo', '~> 2.3.4.5'

would get 2.3.4.5 and up but none† of 2.3.5, and it's up to the project to decide if they want to do any release like that.

† excluding any 2.3.5 prerelease as well

This is approximately how most Haskell libraries are versioned

  -- PVP summary:     +-+------- breaking API changes
  --                  | | +----- non-breaking API additions
  --                  | | | +--- code changes with no API change
  version:            0.0.0.1

[0]: https://pvp.haskell.org/

[1]: https://pvp.haskell.org/faq/

At Bond we’ve used pragmatic versioning with the names:

vMAJOR.MINOR.PATCH[.TWEAK]

Indeed the TWEAK is only for hotfixes, though due to pushback from other devs using semver parsers, we've had to hold back on the tweaks. (Though it’s awkward in a hot fix situation.)

But I like the names the repo author proposes.

Yep, originally I wrote BIGRELEASE.MAJOR.MINOR but I didn't want to confuse the terms. (The first commit shows this: https://github.com/seveibar/pragmaticversioning/commit/70b76...) Good read :)