Semantic versioning is incorrect?

[domoritz]

2.1 should link to 2.2.0 once it is released but it will instead point to the latest 2.1 release.

[arvind]

Not sure I understand why 2.1 should link to 2.2.0. Could you please explain @domoritz? Thanks!

[jheer]

I don't entirely understand the issue either. Please explain!

[domoritz]

Imagine we have the following versions

1.3.0
1.3.1
1.3.2
2.0.0
2.1.0
2.1.1
2.1.2
2.1.3
2.2.0
2.2.1
2.2.2
2.2.3

In Vega-Embed we figure out whether a spec is supported by the Vega version that embed uses with a semver comparison. A spec is supported if the Vega version is within the supported range of the underspecified version from the spec. If the Vega version is v2.2.1, a spec with v2, v2.1 (because 2.2 has to be backwards compatible), v2.2.1 is supported while a spec with v1.3.2 or v2.2.3 is not supported (asking for a too high version).

Now the question is how we should resolve versions that are in specified in a spec. If a spec specifies the schema version v2.1 then the user intention is to say that they want the spec to use at least Vega version v2.1.0 and at most the latest version v2.2.3. But which schema file do you want for v2.1? I argue that you are saying that the spec should work with v2.1.0 as well so you don't want to validate against the v2.2.3 schema file because it would support features that may not be in v2.1.

My point in this issue is that we are neither doing either of the two resolutions above. v2.1 resolves as v2.1.3. This is neither the latest matching version (which would be v2.2.3), nor the minimum version of the schema (v2.1.0) to only mark specs as valid if they work with the lowest matching Vega version.

(I hope I didn't mess up the versions in my description)