Removal policy for notes on older OCDS versions

[JachymHercher]

1. Do we have/want a policy on when to remove notes concerning previous versions of OCDS? Or are those ad-hoc decisions? If a policy, where should it be documented?

2. What is the policy? For example, with OCDS 1.2, will it be time to remove the notes in https://standard.open-contracting.org/1.1/en/schema/codelists/#method , https://standard.open-contracting.org/latest/en/schema/reference/#parties, https://standard.open-contracting.org/1.1/en/schema/codelists/#tender-status, etc.?

[jpmckinney]

We should have a policy, yes. It would be documented in the handbook: https://ocds-standard-development-handbook.readthedocs.io/en/latest/index.html

Firstly, I started using Sphinx's deprecated, versionadded, and versionchanged directives in #1392 in OCDS 1.2 to indicate such changes. They aren't styled yet, but the intention is to use a consistently styled box.

Initial thoughts:

1. Deprecation notices (which should use the deprecated directive) remain until the next major version (2.0). Until the feature is removed in that major version, the notice needs to remain.
2. versionadded (e.g. a new codelist) and versionchanged (e.g. a new code) can perhaps remain for 1 or 2 minor versions. So, something introduced in 1.1 will have a notice until 1.3 at the latest.

Currently, only the parties notice is longer than a line.

In practice, since we aren't planning on a 1.3, nothing will change before 2.0.

You can see the unstyled content at:

• https://standard.open-contracting.org/staging/1.2-dev/en/schema/codelists/#method
• https://standard.open-contracting.org/staging/1.2-dev/en/schema/codelists/#tender-status
• https://standard.open-contracting.org/staging/1.2-dev/en/schema/reference/#parties