You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 of23.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" of23.1
, but it is not; it is a flavor for23.2
which only a binary from the 23.2 series can understandv1.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.
23.1-2
but for 24.1 we would have something like24.1-pre.2
or24.1-pre-finalization-upgrade-step-2
, orupgrade-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
The text was updated successfully, but these errors were encountered: