This change is 

For 22.2 we did this a bit incrementally. Looking at the pieces, I think this is what should be done for 23.1 (also put into this runbook).

Some open questions to still address:

1. what to set for pkg/build/version.txt: for master? to backport to the release-23.1 branch?
2. what should we be doing here for BinaryVersionKey (if anything)? maybe @healthy-pod

For 1, I think maybe this should happen:

• for release-23.1 branch: pkg/build/version.txt value becomes beta.1 (although if we still have release blockers then this should be alpha.8)
• for master branch: we won't be able to add the v23.2-alpha.00000000 tag onto master until we've initialized tests for 23.2 development. however, since we don't plan to release from master after the branch cut, maybe it's okay to keep version.txt as-is until the v23.2-alpha.00000000 tag is in place

what should we be doing here for BinaryVersionKey (if anything)? maybe @healthy-pod

I think we should change this to V23_2 but I will let someone else confirm. cc @dt

I don't think we will bump min supported version but it might help to update tenantCreationMinSupportedVersionKey so we don't have to bump it every time min supported version changes (doesn't need to be in this PR). cc @ajstorm

diff --git a/pkg/sql/tenant_creation.go b/pkg/sql/tenant_creation.go
index f3d41fa8690..44c193400e1 100644
--- a/pkg/sql/tenant_creation.go
+++ b/pkg/sql/tenant_creation.go
@@ -43,10 +43,6 @@ import (
 	"github.com/cockroachdb/redact"
 )
 
-const (
-	tenantCreationMinSupportedVersionKey = clusterversion.V22_2
-)
-
 // CreateTenant implements the tree.TenantOperator interface.
 func (p *planner) CreateTenant(
 	ctx context.Context, parameters string,
@@ -159,8 +155,8 @@ func (p *planner) createTenantInternal(
 		// Use the previous major version to create the tenant and bootstrap it
 		// just like the previous major version binary would, using hardcoded
 		// initial values.
-		tenantVersion.Version = clusterversion.ByKey(tenantCreationMinSupportedVersionKey)
-		bootstrapVersionOverride = tenantCreationMinSupportedVersionKey
+		tenantVersion.Version = clusterversion.ByKey(clusterversion.BinaryMinSupportedVersionKey)
+		bootstrapVersionOverride = clusterversion.BinaryMinSupportedVersionKey
 	} else {
 		// The cluster is running the latest version.
 		// Use this version to create the tenant and bootstrap it using the host

I think we should change this to V23_2 but I will let someone else confirm. cc @dt

This makes sense to me. I'll advance BinaryVersionKey to V23_2, as part of this commit: clusterverion: start 23.2 dev versions clusterversion: define 23.2 placeholder key

for pkg/build/version.txt

For version.txt, I'll set this to v23.1.0-alpha.8 [will add to commit that get backported this week]:

• We have enough release blockers (https://go.crdb.dev/23-1-blockers) where an alpha feels more realistic than a beta for this week.
• I think this master version.txt can stay at v23.1.0-alpha.8 until we've initialized tests and tagged master with v23.2-alpha.00000000

it might help to update tenantCreationMinSupportedVersionKey ...(doesn't need to be in this PR).

ack :)

although if we still have release blockers then this should be alpha.8

Just to confirm if I understand it right: do we release another alpha (off of release-23.1) depending on the status/amount of release blockers?

I think this master version.txt can stay at v23.1.0-alpha.8 until we've initialized tests and tagged master with v23.2-alpha.00000000

Makes sense to me. At that point, we'd update version.txt to be 23.2-alpha.00000000 as well, yes?

Just to confirm if I understand it right: do we release another alpha (off of release-23.1) depending on the status/amount of release blockers?

Correct/exactly, i.e.:

• once we cut the release branch, we should no longer select 23.1 candidate SHAs off of master
• what we end up calling the 23.1 candidate SHA depends on blocker status (if we still have release-blockers, we should all it an alpha. but still select the SHA from release-23.1)

Makes sense to me. At that point, we'd update version.txt to be 23.2-alpha.00000000 as well, yes?

Yes. We should add a task in the initialized tests for 23.2 development runbook to update version.txt to be 23.2-alpha.00000000 at the same time we add the tag to master (I'm happy to do this if no one else gets to it first).

flake - Bazel Essential CI (Cockroach) UnusedLint: "Error in fail: generate_build_file.ts failed". retriggering.

TFTRs!

bors r=dt,rail

bors r-

Canceled.

bors r=dt,rail

Canceled.

failing due to this: #99238

=== RUN   TestCCLLogic_multi_region_show
    test_log_scope.go:161: test logs captured to: /artifacts/tmp/_tmp/f13500f29c3025cd2940e1d8c6d1d42b/logTestCCLLogic_multi_region_show1689673478
    test_log_scope.go:79: use -show-logs to present logs inline
    logic.go:1470: range ID 63 end key not split

bors r+

Build succeeded:

• Bazel Essential CI (Cockroach)