Or maybe we should hardcode it! Patrik has pointed out to me that we don't want the version to change anymore once we're working on 2.2. But we do want to change it when we update 2.1 any versions in the 2.1 branch.

If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc.

I'm not sure what the best solution is. We want something low overhead and we also want to make sure we don't forget to update these versions.

Updating tickets (#2229, #2233, #2297, #2509, #2644, #2695, #2713, #2737, #2741, #2756, #2761, #2764, #2783, #2765, #2759, #2760, #2774, #2775)

To summarize, we have two options
1) hardcode everything in the migration guide, which makes it possible to include old migration guide in new version
2) use variables (and compiled code samples of new code), and only link to old migration guide in new version

I don't think we should do anything for 2.1.x, but something to decide for 2.2

I think we should hardcode it in the migration guides. They are not intended to change for each version.

not completely invalid
I agree that hardcoding in migration guide is the best solution, but as Rich pointed out: "If we do want it hardcoded then maybe we also need to hardcode the Scala version that is currently a variable in the doc."

we don't need to hardcode scala version in "current" migration guide, but it must be fixed in migration guide for older versions, e.g. migration-guide-2.0.x-2.1.x.rst in master, otherwise that file will be wrong when we switch to 2.11.x