Clarify whether unreleased changes should be implemented or not

[tigrannajaryan]

Otel spec is released monthly. Between the release we submit PRs and make changes to the spec repo, accumulating unreleased changes.

Occasionally changes are disputed after merging, with the possibility of reverting the changes before a release is made, see for example #2726

Question: should the unreleased changes considered to be official part of the spec or they only become part of the spec once the release is made?

[tigrannajaryan]

@open-telemetry/specs-approvers what do you think about this?

[Oberon00]

Question: should the unreleased changes considered to be official part of the spec or they only become part of the spec once the release is made?

I think the process does not really suggest that releases are a potential point of re-discussion or even sign-off of changes?

[dyladan]

In JS we commonly implement unreleased changes, especially when we have opened an issue and something is clarified in response to our issue. Waiting for the release may slow down a process that some already see as too slow. I would suggest this policy should only apply to stable released packages.

[tigrannajaryan]

Here is what I would like to propose:

• Changes to the stable parts of the spec are not considered binding until a release is made that incorporates these changes.
• If a mistake is made in the spec and the erroneous change is discovered before the release it is acceptable to revert the change even if the change is in the stable part of the document.
• Unstable implementations are free to do what they want. They can freely implement unreleased spec changes.
• Stable implementations may begin implementing unreleased spec changes but the implementations must hold their release until the spec release which adds the change is made. In other words, stable implementations MUST NOT release changes before the spec is released that incorporates the specification of these changes.

I think this is a good tradeoff. We retain flexibility to fix mistakes, allow implementations to work faster, but still have mechanisms in place to catch spec mistakes and avoid making such mistakes part of stable implementation releases.

Thoughts?