In the reference: Carefully document what our semver actually guarantees
We should document what we exactly are promising about our future semver guarantees. In other words, what counts as a new feature, and what counts as a breaking change?
As a first cut, I would say it is clearly a breaking change if:
- Any template that conforms to the specification, and which is currently accepted becomes rejected.
- Any spec-conforming template that currently applies to a type successfully stops applying to that type.
- The specified output of a template as applied to a type becomes semantically different.
I am not sure when these count as a breaking change:
- A template that does not conform to the spec stops being accepted.
- A template that does not conform to the spec stops applying to a type.
- Other unspecified or under-specified behavior changes in a way that becomes semantically different.
We need to be careful when considering code that becomes accepted. We could say something like "it is not a breaking change for a rejected template to become accepted, or for code that previously previously produced a compiler error to start working instead." But that isn't quite right: our users may rely on some expansions failing on some types. (As a trivial example, it would be a breaking change if expanding ${error}
stopped producing an error.). So instead, we probably need a more nuanced statement here.