Table of Contents
v7.0.2: Guarded rolling updates and community reminders
| Status | Qualified and queued for the owner's next all-four-rooms-empty maintenance window; not yet observed active at this review |
|---|---|
| Review | October 14, 2026 (Pacific time); the running owner controller remains v7.0.1 dev10 |
| Operator distribution | The latest published private installer remains v7.0.1 dev12; this owner controller artifact is not a new general operator release |
Updates that wait for players
Compatible room-worker changes can be approved and queued separately from the account-owning controller. Each selected room waits until it is empty and idle, then uses the native admission lock, roster checks and safe handoff. Occupied sibling rooms keep their matches, workers and join links. Updated rooms receive new room IDs; Live Lobbies follows their current links.
The existing owner controller needs one initial coordinated upgrade before that workflow becomes available. Its queued operation waits for all four rooms to be healthy, empty and idle continuously for 30 seconds, then locks admissions and waits at least 15 more seconds while checking for late joins. The timer checks roughly every 20 seconds, so switching can begin about one to two minutes after the rooms naturally become empty; closure, validation and startup take additional time. Players are never removed to create the window. A late join cancels admission and postpones it.
After activation, compatible individual-room updates use the native five-second empty/idle window and two-second admission drain, plus preparation and health checks. Shared controller, referee, Discord, dependency or storage changes still need a separately reviewed coordinated upgrade. This is not automatic execution of arbitrary GitHub releases.
Preserved state and recovery
The coordinated switch preserves the saved room settings, gameplay tuning, authorization, Discord and website integrations, full catalog pointers, historical feedback and hub enrollment. The network agent returns to its prior operating state. Runtime version labels change; saved gameplay preferences do not reset.
Candidates are checked against protected code, interpreter, dependency and storage contracts. A failed candidate may safely roll back to the previous worker; a failed attempt needs explicit requeueing rather than an endless retry loop. Uncertain ownership remains held for review. Partial controller upgrades do not automatically repeat room creation. This does not promise isolation of every possible fatal service failure.
Website and Discord reminders
The existing post-match community reminder alternates between the website and the configured Discord invite. Owner rooms retain their 2,400-second interval (40 minutes); this is checked at appropriate post-match opportunities, not a promise of a message at an exact wall-clock time. Each unchanged audience is spared repeat notices for a link it has already seen. Empty or silenced rooms do not consume a reminder, and no configured Discord invite means website-only notices. .discord still returns the invite on demand.
Qualification and rollout boundary
Full prepared Standard, 4K and 7K catalogs were used in installed donor qualification with invented external players/provider traffic. Checks covered the real systemd timer, late joins, protected approvals, deliberate worker failure and rollback, occupied siblings, retained shared connections, clean shutdown and restart. Production credentials were excluded from testing. Affected regression checks passed; unchanged whole-project/research suites and new actual osu! gameplay acceptance were not repeated for this batch.
This page records a dated queue observation, not automatic proof of activation. Use fresh room status and the protected operator deployment status for current rollout evidence.
Update behavior and timing · Operator commands · All releases