Handling mixed spec-version objects without version inventories

[zimeon]

If there are no version inventories then one can only tell that the spec version of a prior object version is the same or any prior spec version compared to that declared for the latest object version (for which there must be an inventory). This is made clear by https://ocfl.io/draft/spec/#conformance-of-prior-versions . What are the implications of this with respect to validation and conformance? I think we should understand this before we release 1.1.

[zimeon]

2021-12-21 Editors lean toward adopting an explicit solution to this in 2.0, which might be either:

• Adjust the inventory.json schema to require a version number to be specified for each version, or
• Require a Namaste file for each version (which would also avoid issues with missing version directories)

For the immediate case of version 1.1, we are dealing with backwards compatible changes so it should be OK if the validator can't tell whether a prior version directory is 1.0 or 1.1. Need to check this with #570

[julianmorley]

Discussing this on the editors call, we think there are few, if any, implementations that create version directories without inventory files and a validator could try validating a version against 1.0 and 1.1 and flag an error if neither worked. So we decided to defer this potentially breaking change to 2.0.

[rosy1280]

Working Definition for a Breaking Change :

• a 1.1 tool would flag a valid 2.0 object as invalid
• a version 2.0 tool would NOT flag a valid 1.1 object as invalid