(release, major, minor) is honestly how versions often get used in the wild. Esp...

lloeki · on Dec 5, 2023

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

kamov · on Dec 5, 2023

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/

clbrmbr · on Dec 6, 2023

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.