Provide a version requirement expression rather than a version list

[passcod]

Given the spec versions are semver, semver requirement expressions could be used instead of a static list.

Currently a plugin cannot advertise that it supports 1.0.0 and compatible specs with higher versions (1.0.1, 1.1.0, ...), for example, without either being updated to include each subsequent spec revision in its list, or responding to the VERSION command dynamically.

If it's instead intended that implementations shouldn't try to support future (semver compatible!) versions, that should be indicated somehow.

[squeed]

This is a very interesting question - and it led to some discussion: under what circumstances would we ever touch the patch version? In other words, what semver-compatible change would result in spec version 1.0.1?

We couldn't come up with anything immediately - we're considering pinning the patch version to 0 in the spec.

Thoughts, @passcod ?

[passcod]

I can't either see anything that would cause a need, especially with this spec's policy that the version tags aren't frozen (thus, I assume the idea is, minor but semantically significant 'bugs' can be "fixed" without needing a formal patch bump).

If the patch version is frozen, then the question may also be raised as to if it may be dropped entirely from the JSON (with the note that "an implementation may consider it implied to be suffixed by .0 for purposes of version comparison", perhaps).

Also for discussion under the same umbrella: policy around prerelease forms of the version?