Version compatibility with an evolving spec

[wking]

The current docs say:

If the container is compliant with multiple versions, it SHOULD advertise the most recent known version to be supported.

That's going to make backward compatibility with old tools hard. I'd rather take major and minor numbers from semantic versioning, so a v1.3 config would be compatible with a v1.3 launcher, or a v1.4 launcher, etc., etc., but not a v1.2 launcher or a v2.0 launcher. That gives you some granularity for specifying which of several compatible features you need (e.g. UID-mapping for #10 was only added in v1.3, but v1.3 launchers can still handle the v1.0 containers).

One limitation to the sem-ver appoach is that feature addition needs to be serialized. If you have to orthogonal extensions, and A lands in v1.3 while B lands in v1.4, implementations that want to support feature B also need to support feature A. For example, Notmuch uses feature tags to mark supported optional features (which is what sem-ver's minor releases are for).

So depending on how flexible you want to make life for spec implementors, I'd recommend chosing either sem-ver (simple, some cross compatibility, serialized features) or feature tags (more complicated, lots of flexibility, parallel features). Having a single integer that spec authors are supposed to bump (the current recommendation here) gives you essentially zero cross-compatibility without building the list of changing features into the implementation itself.

[philips]

For now I am OK with a linearized release process. If we find a need later we can re-evaluate.

[wking]

On Thu, Jun 25, 2015 at 09:52:13AM -0700, Brandon Philips wrote:

For now I am OK with a linearized release process.

Sounds good. Can we use sem-ver then to provide cross-compatibility
between a given config and implementations at different minor-versions
of the spec?

[jonboulle]

+1, specifically SemVer 2.0.0

[crosbymichael]

+1

[philips]

Fixed via 9c90ccd

[wking]

For now I am OK with a linearized release process. If we find a need later we can re-evaluate.

Parallel spec platforms are a lot like parallel features that are unlikely to ever be unified. And a seperate, optional-to-implement VM layer (#405) is too (discussion in #935). Perhaps it's time to re-evaluate? An "I require these features" property could be added to a 1.1 spec, even if it's REQUIRED, withought breaking 1.0.x configs.