On Wed, Dec 13, 2023 at 15:28:47 +0200, Ran Regev via SG15 wrote:
> Why not simply _add_ a version / revision object in the file?
>
> After a while, deprecated, unsupported versions can be deleted.

The rules (that I suspect are alluded to here) have roots in P1689R5§7:

    There are two properties with integer values in the top-level JSON
    object of the format: version and revision. The version property is
    required and if revision is not provided, it can be assumed to be 0.
    These indicate the version of the information available in the
    format itself and what features may be used. Tools creating this
    format should have a way to create older versions of the format to
    support consumers that do not support newer format versions.

    The version integer is incremented when semantic information
    required for a correct build is different than the previous version.
    When the version is incremented, the revision integer is reset to 0.

    The revision integer is incremented when the semantic information of
    the format is the same as the previous revision of the same version,
    but it may include additionally specified information or use an
    additionally specified format for the same information. For example,
    adding a modification_time or input_hash field may be helpful in
    some cases, but is not required to understand the dependency
    information. Such an addition would cause an increment of the
    revision value.

Adapting wording for here, we only bump the major version when there is
a new field that affects correct usage of the information presented
(e.g., a new hypothetical boolean that means "ignore consumer flags" or
something). Such a file cannot be understood correctly and older
versions cannot be claimed. For a revision, something like "ignore all
warnings" would be a revision update. If you understood X.N, X.N+1 is
not fatal to a *correct* usage, just might be noisier.

Given this, how would we claim multiple versions here?

--Ben