This change is 

As I understand it, VersionStart20_2 is the right version here because it includes all the 20.2 prereleases, and setting it to Version20_1 last time (instead of VersionStart20_1) was incorrect. I'm going off of @andreimatei's comment here.

I think we got confused on the same point last time too: #49590 (comment)

Okay, having read the issue, I think Version20_2 does make more sense. I'll update it.

It does feel a little weird to set the minimum supported version to a version we just created. I'm concerned about breaking things unexpectedly because of this. Let's see what happens on CI first of all.

I think the idea is 21.1 is only compatible with 20.2, and thus 21.1 work only needs to consider 20.2 when handling mixed version, not whatever mid-cycle development versions came before 20.2.0 (which could be as old as basically being 20.1).

Rebased on top of #56163.

I think once this merges, we can finally tag something on master as v21.1.0-alpha.00000000.

The problem now is that for acceptance/version-upgrade to pass in the CI tests, I need the build to be tagged as v21.1.0. I guess I could tag an earlier commit instead, but that doesn't seem right.

Hmm, I think the way to do this might be to just bump binaryMinSupportedVersion in a later commit after v21.1.0 has already been tagged on master. Let me try that.

This PR now only bumps binaryMinSupportedVersion, like it did originally. (There's also another commit to get rid of a mixed-version test that we don't need anymore.) acceptance/mixed-version now works locally for me, so let's try this.

bors r+

Build succeeded:

• GitHub CI (Cockroach)