clusterversion: bump binaryMinSupportedVersion to 23.1

[rail]

We need to bump binaryMinSupportedVersion to 23.1 before we release the first 23.2 beta (branch cut is currently scheduled for Oct 10).

TODO:

1. [release-blocker] PR 1 - bump minBinary, adding skips to all the tests that fail.
2. Create tracking issue(s) for tests skipped in (1). Then assign to teams so they delete whenever.
3. Rename / prefix 23.1 gates with a TODODelete_ prefix or something, so when teams see if in the code they know they can clean up related code.
4. Create tracking issue(s) to delete 23.1 gates. Then assign to teams so they delete whenever.

Also tracked in https://cockroachlabs.atlassian.net/browse/REL-506

Jira issue: CRDB-32062

[RaduBerinde]

I think we should rename things like local-mixed-22_2-23_1_test to `local-mixed-with-previous-version' so we don't have to rename it every time. Can be done separately so it's just a mechanical change.

[dt]

rename things like local-mixed-22_2-23_1_test to `local-mixed-with-previous-version'

This is actually the opposite of a change we elected to make a couple versions ago. Having the old version name explicitly in the test makes it easier to know that you can delete that config when we are no longer testing behaviors specific to that version, without needing to know what exactly those behaviors are.

Having it implicitly move up to test a new different version is much harder, in practice, since the person making that change is typically a release engineer, who is then facing a test that starts failing since the behaviors it thought it was testing - 22.2 behaviors -- changed since it is now testing against a different version. The feature-area engineers should be the ones writing tests that encode the expected behaviors of their feature area in a specific -- and explicitly named! -- version and then the release engineering folks just need to know that if they're changing what versions we want to test, certain we'll-labeled feature tests are or are not applicable.

[RaduBerinde]

Oh, that makes sense - I was reacting to the (draft?) changes in #111768. Looked like that PR renamed local-mixed-22.2-23.1 and all uses of it to local-mixed-23.1-23.2..

I think we're missing a comment with some guidance above where "local-mixed-22.2-23.1" is defined about how to move forward when 22.2 is no longer supported.

Also, it feels like the name is not exactly correct, it should be local-mixed-22.2-current or local-mixed-with-22.2

[RaduBerinde]

One question though.. why is there no local-mixed-23.1-current config? Do we really have no post-23.1 migrations to test?

My hunch is that we're using local-mixed-22.2-23.1 config to test both migrations in 23.1 and migrations in master (i.e. 23.2) and disambiguating this will be a pain.

[RaduBerinde]

Here is my (updated) plan of action:

• bump min supported to 23.1
• remove logictest config local-mixed-22.2-23.1 and add local-mixed-23.1; skip the latter config on all failures caused by features added in 23.2
• remove pre 23.1 version gates
• fix up/remove any tests that involve 22.2

The changes above are backported to release-23.2.

Then, only on release-23.2:

• mint the 23.2 version

Then, only on master:

• add 23.2 version, switch to 24.1 version
• add logictest config local-mixed-23.2
• add a way for the binary to choose between setting 23.1 or 23.2 min supported version

[celiala]

Of the 4 TODOs listed, only item 1 is the release-blocker (items 2-4 don't block the release and can be done anytime).

Removing the release-blocker label, since item 1 is now complete and backported.

[RaduBerinde]

2 is done too, I had to skip a couple and I filed issues. Working on 3 and 4 right now.

[RaduBerinde]

#112501 is merging soon. Filed #112501 for tracking the removal of the old gates.