On Wed, May 17, 2023 at 16:47:06 +0000, Charles-Henri Gros via SG15 wrote:
> If we allow only closed intervals, which I really think we should, and
> we really care about parsers that do not actually parse the JSON, then
> I repeat my suggestion of an "a-b" syntax.

Note that being too strict here means that if a tool releases with (say)
version 1.2.3, everything using it needs to be updated to include that
version in their compatibility range. Imagine if you had to wait for a
new CMake release for any compiler release for them to claim to support
each other. If we thought the C++ ecosystem was deadlocked and hard to
work with today, that sounds even more daunting to me.

> If we do only have monotonic increases, then I'm not completely sure
> I'm on board with the a.b.c versioning scheme. The "small change" vs
> "large change" distinction doesn't seem worth encoding in the version
> number if I have to claim exact support anyway.

I don't think anyone can guarantee that new releases will keep support
for anything in older versions. The component-wise versioning
communicates whether one can expect to update without issues. I'd be in
favor of just importing SemVer-like semantics[1] (and its comparison
operators) with guidance like:

- patch-level changes should be compatible with any other
  otherwise-similar version numbered release ("bug fixes; I'll specify a
  minimum patch level if one affects me")
- minor-level changes should be compatible with any same-major,
  larger-minor release ("new features added, but I don't need them")
- major-level changes mean "please retest your compatibility as we may
  have removed functionality you were relying on" and will, generally,
  require ecosystem syncups to claim compatibility

--Ben

[1] Importing SemVer itself into ISO is probably a whole different beast
as I suspect it is outside of the ISO "allowed to reference" list.