Decide whether next update release should be 1.1.1 or 1.2

[zimeon]

There are a number of changes in the draft specification since the 1.1 release -- diff can be seen by change in draft/spec.index.md from tag 1.1 to now. This drift has led to confusion (e.g. #646)

Most changes are simple clarifications and formatting fixes which would suggest a 1.1.1 release.

However, in response to #528 we removed a MUST that was agreed to be meaningless. Changed text around line 766 from:

3. File paths and filenames in the OCFL are case sensitive. Filesystems MUST preserve the case of OCFL filepaths and filenames.

to:

3. File paths and filenames in the OCFL are case sensitive. Implementations over filesystems that either do not preserve case or are not case sensitive require great care, including making appropriate choices for file paths and filenames.

Does this warrant 1.2?

[zimeon]

My feeling is that because we agreed that the MUST was meaningless, and instead it was better to write a warning about implementation, this is not therefore significant change. I think all changes are thus clarifications/bug-fixes and we could release as 1.1.1. However, we have just one date on the specification ("7 October 2022" just under the title on https://ocfl.io/1.1/spec/) and no sensible mechanism to describe updates from 1.1 to a 1.1.1 so that makes me lean toward releasing as 1.2, in order to avoid any confusion about what has (or hasn't) changed.

[zimeon]

The downside of 1.2 is that we clutter the notion of versions of the specification that objects might comply with -- for no actual change in objects between 1.1 and 1.2.

[srerickson]

My two cents as an implementer: releasing these changes as v1.2 would needlessly complicate things. In addition, I like the idea of using patch releases to make improvements to the spec that don't affect object structure and validation.

[zimeon]

I agree, @srerickson, the right question for whether changes rise to the level of a v1.2 is whether there are any changes to object structure and validation. We shouldn't create additional complexity for implementation (which any major or minor version does, but not patch releases) unless there are such changes.

Given this. I think we should be heading to a v1.1.1 and then the question becomes how best to show that in the specification. I think we need to make it plain the update date even though as v1.1 the main date is perhaps still the original release data of v1.1. We might then add a revision history for v1.1 at the foot of the document that provides access to all patch versions, release notes, and diffs. Perhaps something like:

Oxford Common File Layout Specification

7 October 2022, last updated 99 September 2024

This Version:

https://ocfl.io/1.1/spec/

... spec in here ...

Revision history

Version	Date	Description
v1.1.0	7 October 2022	First v1.1, release notes
v1.1.1	99 September 2024	Bunch of fixes for X & Y & Z, release notes, diff

[rosy1280]

@zimeon can you update this ticket with the decision and approach that we will take with regard to the next version of OCFL?