chore(release): promote rc-2026.8.3 - #217
Merged
Merged
Conversation
Semver ranks a final above its own pre-release, so a node running 0.18.0-beta.1 treated the promoted 0.18.0 as an upgrade and applied it. That is a binary swap and a network restart for the same code re-tagged, and because the train promotes every cycle it happened on every train, to every beta node. It also quietly dissolved the cohort: a node enrolled in the beta programme spent part of each cycle running a stable build. On the beta channel a final is no longer a candidate when the running version is a beta pre-release of the same major.minor.patch. The skip is deliberately narrow — a genuinely newer final is still taken so a node does not stagnate if the beta line stalls, a later beta of the same version is still taken, and a node running a beta while configured for stable still takes the final, since that is its route back to the stable line. This depends on the pair (candidate, running version) rather than the candidate alone, so it sits beside the channel predicate rather than inside it. The beta-identifier test is now a shared helper so the two callers cannot drift. Accepted limitation, recorded in the ADR: if code changes between the last beta.N and the final without a new beta tag, a node skipping the promotion misses it until the next version. That is a process obligation on the train, not something the node can detect. Tests: 30 passing in upgrade::monitor, five new covering the skip, the newer-final case, the next-beta preference, beta.2, and stable being unaffected. Clippy, rustdoc and fmt clean. V2-1044 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review of the previous commit found that the skip fired only for the beta a node was already running, not one it had selected but not yet applied. A node part-way through its staged rollout for 0.19.0-beta.1 is still running 0.18.0-beta.1, whose core differs from 0.19.0, so the final was not marked redundant and outranked the pending beta. The node applied the final and never ran the beta at all — meaning whether a node kept its beta identity depended on where its rollout jitter fell. Selection now compares against the build the node is committed to: the pending staged-rollout target when there is one, otherwise the running version. The "is it newer" guard deliberately stays on the running version, so a withdrawn pending release cannot leave a node refusing everything still published. ADR-0010 is corrected on a related point. It claimed promotion re-tags the same code; it does not. Dependency references flip from git branch pins to published crates.io versions, so a final is not byte-identical to its beta. The skip is safe for a different reason: any change landing on the RC branch produces a new beta, and the final is promoted from the most recent one, so no final carries code that no beta carries. The ADR now records that, along with its dependence on old beta releases staying published, and lists both as properties the node cannot verify. Tests: 32 passing in upgrade::monitor. Two added — a node holding its pending beta against that beta's promotion, and the same release pair without a pending target still resolving to the final, which documents why threading it through is necessary. Clippy, rustdoc and fmt clean. V2-1044 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
fix: stop beta nodes restarting onto their own promotion
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Promotes
rc-2026.8.3to release version(s): 0.17.2.-rc.*from[package].versionCargo.lockOnce merged, the release tag will be pushed to fire the publish workflow.