Proposal: Use semver instead of dates for schema IDs

[michaeltlombardi]

Using $schema rather than a semver version requires forward compat to just give parsing a try and hope that anything that would be considered a major version change isn't still parsable by an older client. (Alternatively, you can just have no forward compat.)

Have you considered embedding a semver version number in the schema URL to enable forward compatability?

Originally posted by @JohnMcPMS in #94 (comment)

[michaeltlombardi]

Thinking about this again, one of the things we might want to do, because hosting the schemas is relatively cheap, is publish the schemas at multiple URIs (possibly just by adding redirects):

• A canonical URI based on the semantic version of the schema itself, indicating breaking changes/additions/etc. This will be more important after alpha to provide an indication of whether or not users can expect any changes for the schema between versions.
• The date-based URI, which we use now, as an alias.
• An alias URI based on the compatible DSC version. In this case, when the same schema applies to multiple versions, we publish it to each URI. This would make alpha.1, alpha.2, and alpha.3 use the same schemas, but accessible at .../v3.0.0-alpha.1/..., .../v3.0.0-alpha.2/..., etc.

The other thing we could (should?) do is add a $comment to the schemas indicating which version(s) of DSC they are compatible with, so anyone reviewing the schema can quickly identify the releases it works with.