Open srerickson opened 2 years ago
This is an interesting question. I consider this promise to already be present because:
But maybe something more should be spelled out? This does, of course, rely on software maintaining support for all prior versions.
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.
We would like to defer this to 2.0 so we have something more substantive to talk about regarding compatibility.
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:
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?