Name the release 2.2.0, and say what the pinned AssemblyVersion does not cover (#746)

[Rafael-SOWNet]

The last checklist item before 2.2.0 can be tagged. Version and FileVersion move to 2.2.0, and BREAKING-CHANGES.md's Unreleased section becomes 2.2.0 — since 2.1.0.

And a correction to the comment on the pin

AssemblyVersion stays 2.0.0.0, as it has for the whole of 2.x. The comment explaining why said that holding it there "makes every 2.x release a drop-in replacement".

That is true of binding and not of compatibility, and this release is exactly where the difference shows. 2.2.0 renames two members that shipped in 2.1.0, so a consumer that swaps the assembly without recompiling still binds — and then throws MissingMethodException when the call is reached.

I had written the BREAKING-CHANGES entry claiming the rename "breaks a build rather than an answer … there is nothing to discover at runtime". The pinned AssemblyVersion is what makes that wrong, and it is wrong in the direction that matters, so both the comment and the entry now say which of the two the pin guarantees.

The number

Checked against #746 rather than picked: 2.2.0 advances tier 1 and completes none of it. The polynomial layer is done, canonical form is specified and implemented in both halves, and expression metadata is retired as having no consumer; pattern-matching-as-data is begun but internal, and the per-commit corpus is not wired into CI. Nothing of tier 2 ships. The note recording that is on the issue.

Strict semver would read a rename of a shipped member as a major. This project has not: 2.1.0 shipped a dozen changed answers under a minor, on the stated principle that correctness outranks compatibility. A rename is a weaker break than a changed answer, so 2.2.0 is consistent rather than an exception — stated explicitly here rather than left as an inference.

Measured, on a build of the merge commit rather than on a branch

suite	7117 passed / 0 failed, 14 skipped
casbench	116/119 solved, 0 wrong, 0 error, 0 timeout — identical to the committed baseline
canoncheck	canonical form: 0/834 idempotence, 0/2738 order failures; every column matches the committed baseline exactly
rulecheck	30 sets, 1365 applications, 0 that never settle, 0 value changes

crashcheck and docsamples are running against the same build; I will post their results here rather than tag without them.

🤖 Generated with Claude Code

[Rafael-SOWNet]

The two that were still running, on the same build of the merge commit (3e3a3911):

crashcheck	1652 cases — 0 crashed, 0 did not finish, 0 threw something unexpected; 1549 returned, 103 declined. Identical to the committed baseline line for line.
docsamples	84 samples over 19 pages — 0 compile errors, 0 output mismatches, 0 threw, 0 did not finish; 57 outputs verified, 20 not stated by their page, 2 compile-only, 5 skipped.

docsamples is the one that was worth waiting for here rather than assuming: it compiles the wiki's samples against this build, so a page using Transformation.Rationalisation would have failed to compile. None does.

That closes the release checklist — suite and harnesses green and read rather than summarised, a BREAKING-CHANGES entry per changed answer, the performance pair published in #939, the number checked against #746 with the tier note on the issue, and the wiki's samples still true.

All six harnesses were run against a git archive export of the merge commit, not against a branch and not against the workspace's submodule checkout, which is still eleven commits behind.