Add Semver support as built-in type

[vilherda]

Hello,

In the same way as there is support to date and time types, it will be so useful to add support to a new type to represent data on fields declared as "semver", by example.

I supose that "everyone" knows about, but just in case, here is the URL of the standard:

• https://semver.org/

Regards

[handrews]

This is the sort of keyword that is best handled through an extension vocabulary (see the $vocabulary documentation in the spec). We are not adding more to format (it should be replaced by vocabularies, although we won't officially deprecate it unless/until replacements are available and widely accepted).

[jamesodhunt]

@handrews - Can you explain how that would work? Is the intention for the JSON Schema standards group to provide standard vocabularies for the existing date, date-time, email? If so, do you think the standards group would consider adding semver to that standard set of vocabs? For good reason semver has essentially become the de facto versioning scheme in use today so it would be great to be able to validate schemas using such versions )without everyone having to reinvent the pattern matching for semver).

On a related topic, I wonder, if that were to happen, whether the JSON schema itself would move to semver rather than just a version encoded as a date? 😉

[gregsdennis]

An alternative would be to use a pattern keyword with the regular expression ^[0-9]+\.[0-9]+\.[0-9]+$ (or ^[0-9]+\.[0-9]+\.[0-9]+(-.)?$ to support prerelease versions).

[jamesodhunt]

@gregsdennis - that's only partially true: semver is richer than that, supporting versions like:

• 1.0.0+21AF26D3-117B344092BD-foo-bar.wibble341-2.5a

I just noticed that the FAQ at the end of https://semver.org/ now lists two regex's for semver:

• ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
• ^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

I think those alone are reason enough to consider inclusion in the JSON schema spec as we really don't want them to be proliferated too much! ;) Plus, consider the potential scope for getting them wrong if trying to construct from scratch.

Related to my comment about the version format of the JSON Schema version, I appreciate these are different organisations, but I noticed earlier that the ASDF YAML spec (based on http://json-schema.org/draft-04/json-schema-validation.html) uses semver for its own version:

• https://asdf-standard.readthedocs.io/en/1.6.0/schemas/yaml_schema.html

[gregsdennis]

I think those alone are reason enough to consider inclusion in the JSON schema spec as we really don't want them to be proliferated too much!

So create a new schema:

{
  "$id": "https://myserver.dev/schemas/semver",
  "$schema": "<pick a draft>",
  "type": "string",
  "anyOf": [
    {"pattern": "<regex 1>"},
    {"pattern": "<regex 2>"}
  ]
}

and store it somewhere it can be accessed publicly. Now you can $ref to it whenever you want, and so can I.

My point is that pattern sorts out your problem without having to define a new format or create a new vocabulary, which you seem averse to.

Regarding JSON Schema version, no, semver is not on the table at this time. We've discussed it and decided that's not the route we want to take.

[Relequestual]

If you defined a vocabulary, it would be a similar approach, but would only work with JSON Schema 2019-09 and above.

[Relequestual]

@jamesodhunt: On a related topic, I wonder, if that were to happen, whether the JSON schema itself would move to semver rather than just a version encoded as a date? 😉

No. Semver doesn't actually make much sense for specifications IMHO. It sends the wrong message.
If we did, we would still be pre 1.0.0 anyway, so it would be of little use.

[Relequestual]

Closing this in favour of, @vilherda if you'd like to chat more on your options, feel free to reach out on our slack server. Link on the main site.