Currently, we have the following scheme for intermediary (during upgrade) versions: we start with a release version e.g. 23.1, then we step through variants of 23.1 that have non-zero Internal values, e.g. 23.1-4, 23.1-6. At the end of the upgrade, we switch to the next version, 23.2.

So during an upgrade, we would step through versions 23.1 -> 23.1-2 -> 23.1-4 -> ... 23.1-12 -> 23.2.

There are a few issues with this:

• 23.1-2 looks like a "flavor" of 23.1, but it is not; it is a flavor for 23.2 which only a binary from the 23.2 series can understand
• various code uses the major version (disregarding the Internal) part to e.g. build documentation URLs or expected test results; whenever we mint a new release version, all these places need to be updated
• In standard versioning schemes (like semver), versions that contain a dash come before the corresponding versions without a dash, e.g. v1.2-beta.1 < v.1.2. We don't abide by this ordering.

The proposal is to change this scheme so that intermediary versions have the same release series numbers as the release we're upgrading to.

• existing versions need to function the same, and
• new intermediary versions should have a new string format to differentiate them from the old semantics. For example, we would still have23.1-2 but for 24.1 we would have something like 24.1-pre.2 or 24.1-pre-finalization-upgrade-step-2, or upgrade-to-24.1-step-2.

We can do this either by reinterpreting what Internal means for major versions >= 24, or we can add a new field e.g. PreFinalizationUpgradeStep. In any case, above 24, "final" releases (where neither of these fields is set) will always come after corresponding non-final releases.

Jira issue: CRDB-32562