-
Notifications
You must be signed in to change notification settings - Fork 110
Description
When designing umoci.json I went with the bare-minimum design of a static version number, but this means that if we add new features we will either have to silently add fields (that older umoci versions won't recognise and may result in broken behaviour) or we bump the version number (which will require adding migration / conversion code).
For features that do not modify a field type (which -- to be fair -- has happened before in 4bbafeb) we can probably make do with just having feature flags so that we can add fields. If a user doesn't use a new feature we don't include the feature flag and we get forward-compatibility, while we also get trivial backward-compatibility.
We can probably model this after ZFS feature flags (that also have a concept of read-only-compatible which would apply to optional features which old versions can safely ignore and still act correctly).