Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clusterversion: rework scheme for intermediary versions #112708

Closed
RaduBerinde opened this issue Oct 19, 2023 · 3 comments
Closed

clusterversion: rework scheme for intermediary versions #112708

RaduBerinde opened this issue Oct 19, 2023 · 3 comments
Assignees
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)

Comments

@RaduBerinde
Copy link
Member

RaduBerinde commented Oct 19, 2023

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

@RaduBerinde RaduBerinde added the C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception) label Oct 19, 2023
@RaduBerinde RaduBerinde self-assigned this Oct 19, 2023
@RaduBerinde
Copy link
Member Author

Thanks to @dt for collaborating on these ideas.

@RaduBerinde
Copy link
Member Author

or we can add a new field e.g. PreFinalizationUpgradeStep

This doesn't seem too practical because Internal made its way into system tables and serverpb protos.

@RaduBerinde
Copy link
Member Author

After looking more into this, I think the effort and potential fallout is much too large for the benefit.

@RaduBerinde RaduBerinde closed this as not planned Won't fix, can't repro, duplicate, stale Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Solution expected to add code/behavior + preserve backward-compat (pg compat issues are exception)
Projects
None yet
Development

No branches or pull requests

1 participant