Description
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.