Should OCFL include a compatibility promise?

[srerickson]

Looking toward the release of 1.1 and the possibility of 2.0 on the horizon, it may be helpful to include a non-normative statement describing expectations for compatibility between 1.0 and future revisions of the spec. (Go's "compatibility promise" is an example of such a statement).

In the case of OCFL, such a statement might include the following:

"It is intended that valid OCFL objects created with version 1.0 of the spec will continue to be valid for future OCFL versions."

This specific promise may be unrealistic. Rather, my suggestion is that it would helpful to communicate how the spec may or may not evolve in the future. Are OCFL editors open to placing constraints on future revisions? If so, what are these constraints?

[zimeon]

This is an interesting question. I consider this promise to already be present because:

• a valid OCFL x.y object will always be a valid OCLF x.y object
• the intention is that future versions of the specification will allow objects to include within them prior object versions at any prior specification version per https://ocfl.io/draft/spec/#conformance-of-prior-versions

But maybe something more should be spelled out? This does, of course, rely on software maintaining support for all prior versions.

[srerickson]

I agree that some promises are already present, or latent, in the draft spec and that it would be useful to spell these out. Also, compatibility is possibly a less pressing concern for OCFL than it is for, say, a programming language because OCFL objects declare the exact version of the specification against which they should be interpreted (i.e., "a valid OCFL x.y object will always be a valid OCLF x.y object").

My hope is to identify ways to make implementing OCFL easier since it may become quite challenging to support all prior versions, as required. Rather than compatibility, maybe it would suffice to emphasize stability in the spec wherever it is necessary or possible.

[rosy1280]

We would like to defer this to 2.0 so we have something more substantive to talk about regarding compatibility.