Planned upgrades (UPG) - #423
Merged
Merged
Conversation
…ature/upgrade-plans
…ature/upgrade-plans
Member
|
Looks awesome! One thing: can we edit a plan? I don't see an edit button on the screenshot |
Base automatically changed from
feature/tam-6884-pre-upgrade-migration-testing
to
main
July 30, 2026 21:38
Contributor
Author
added and updated screenshots |
passcod
reviewed
Jul 31, 2026
passcod
approved these changes
Aug 2, 2026
|
|
||
| This spec covers what a plan records, who sets it, when Canopy considers it met, and what reads it. | ||
|
|
||
| It does not cover performing an upgrade. |
Member
There was a problem hiding this comment.
Yet! (don't add this to the spec tho haha)
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
2 participants
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.
Records where each deployment is going, so pre-upgrade testing aims at the version that will actually be applied instead of guessing.
Based on
feature/tam-6884-pre-upgrade-migration-testing, not main. Review that first; this diff is the four commits on top.Canopy knows what every server runs and every version that exists, but not which minor a site takes next, because that is a human call. So migration testing guessed newest, which is wrong for a deployment deliberately moving to an older minor and spends a full restore proving it. And nothing showed which deployments were mid-plan, late, or unplanned.
An operator records per group: target version, optional date, optional note.
candidate_forthen prefers the plan over newest, which is the whole point. Dashboard at/upgradessplits planned from nothing-recorded.Four decisions worth arguing with:
"Plan", not "intent".
intentalready means restore-consumer intent here, and two meanings in one crate would confuse. Mechanical to rename if you disagree.A date is not a deadline. Nothing schedules or blocks on it, and
lateis presentational. An upgrade slipping is normal operational reality, and a date someone typed is no basis for an incident.Overshooting meets the plan. A deployment that jumped further than planned has done the upgrade and then some; holding the plan open would report it as outstanding.
One open plan per group, enforced by a partial unique index. A group goes one place next, so recording replaces rather than queues, and the retired plan is kept as history. That history is what makes "how long do our upgrades actually take to happen" answerable.
Canopy closes a met plan itself by watching what the group reports, so nobody ticks anything off. A target that is unpublished, or not ahead of the group, is refused.
Spec is UPG (
.workhorse/specs/private-server/upgrade-plans.md); RST's candidate rule now points at it.1074 Rust tests green plus 2 Playwright.
server-reachability-silence.spec.ts:121flaked once under full-suite load and passes in isolation; my branch touches nothing reachability-related, but I did not bisect it against main.