What is the policy for updates to previous versions?

[azaroth42]

@scossu in #1876:

Is there a life cycle policy for the specs? I find it reasonable to consider 2.x as a "stable" but not "deprecated" or "frozen" version, i.e. there are no new features added but non-breaking edits for major/critical issues are possible [...]. I understand that this may create additional work for the editors but it seems like more transparent communication.

There is an editorial process for creating new versions of specs. I think there should be a section 1.6 that documents when we would create a new version that is not the newly highest numbered one, and that it should be restricted to security/privacy fixes only. The right solution is to instead implement the new most recent, rather than patching a previous version.

As we have seen from other environments, once the door is open to stay in a previous version and still have updates, then the transition time is extremely long. Python 3.0 was released more than a decade ago, with updates to 2.6 and 2.7 over that time. Only now that 2.x is finally end of life is everyone making good on the transition. We don't have the user base of something like Python to be concerned about for backwards incompatible changes, thankfully.

Given the incompatibilities between 2 and 3 and the strangeness of cross-version references, I think it is best to do everything possible to ensure that organizations update as quickly as feasible. Given the timelines for new minor versions, the speediness of updating implementations to the most recent is likely in the same order of magnitude of updating the previous spec. Further, any issue significant enough to warrant a change to a previous version is highly likely to be backwards incompatible ... meaning that it should be in a new major version anyway. Finally, the number of possible privacy and security implications is very low and likely limited exclusively to auth. Given that no serious issues (that weren't already known, such as not using auth for presentation api) have been raised since its publication, it seems unlikely that this will ever come into play.

With these considerations, I would propose that previous versions will be updated for privacy or security issues. If the fix is backwards compatible, it will be via the creation of a new minor version (e.g. Presentation 2.2). If the fix is not backwards compatible, then the change will be in the form of a warning callout that the issue exists, and the recommendation is to instead update to the most recent version.

[scossu]

Great starting point, @azaroth42 . I agree with "security and privacy" being the parameters to evaluate deprecation / end of life.

We can find a balance between the reality of the editorial group's resources and the implementers' resources (as an opposite example to Python, I have seen other open-source projects create very frequent updates which the adopters have a hard time keeping pace with); but I lean toward your approach combined with gradually slower major changes as IIIF matures.

Some further details may need to be nailed down:

• When is a major version considered deprecated? As soon as a x.0 version is released (i.e. there will never be two major versions receiving regular updates at the same time), or when enough server and client implementations are available to effectively make the transition possible?
• Which terminology shall we use? I would propose three tiers: "development", i.e. receiving regular updates (ex. presentation 3.x currently) ; "stable", only receiving critical updates (2.x); and "deprecated", no longer receiving any updates (1.x).

[zimeon]

Much of this is already captured on https://iiif.io/api/index.html with the terminology "current", "draft" and "older". I don't think the status can be in the spec document else you have to update that to change it, but we could add a few more words on the API page