From 63bbbb1508d9f102cc2679c76825af879d2cb56b Mon Sep 17 00:00:00 2001 From: rcourtman Date: Sat, 4 Jul 2026 10:30:10 +0100 Subject: [PATCH] Refresh v6 GA publication metadata --- docs/UPGRADE_v6.md | 11 +- .../internal/V5_MAINTENANCE_SUPPORT_POLICY.md | 4 +- ...ent-branch-ga-owner-approval-2026-07-02.md | 6 +- ...nown-rc-issue-closure-for-ga-2026-07-04.md | 155 ++++++++++++++++++ ...-promotion-readiness-blocked-2026-04-04.md | 27 +-- .../subsystems/deployment-installability.md | 6 +- docs/releases/RELEASE_NOTES_v6.md | 13 +- .../release_promotion_policy_test.py | 8 +- .../resolve_release_promotion_test.py | 8 +- 9 files changed, 201 insertions(+), 37 deletions(-) create mode 100644 docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-07-04.md diff --git a/docs/UPGRADE_v6.md b/docs/UPGRADE_v6.md index 93b5f1778..7ae804bce 100644 --- a/docs/UPGRADE_v6.md +++ b/docs/UPGRADE_v6.md @@ -79,6 +79,11 @@ After the server is on v6, use the generated install or upgrade command from to v6. A v5 agent can be missing from v6 Reporting until it has upgraded, authenticated, and sent its first v6 report. +Agent self-update still belongs to the agent update path and depends on the +agent being able to authenticate, reach a trusted update channel, and accept +the release signing key. Do not treat the server update alone as proof that +every installed agent has moved to the same v6 version. + ### Will an upgraded v5 agent keep the same identity in v6? Yes. The v5-to-v6 agent path is expected to preserve one canonical agent @@ -118,10 +123,8 @@ servers. ### Can I keep Pulse v5 stable while I test Pulse v6? -Pulse v5.1.35 remains the current stable line while RC7 is evaluated. - -Use a staging or otherwise controlled upgrade first and keep a rollback path -available. For RC7, the stable rollback command is: +Yes. Keep a rollback path available while you evaluate v6. For the v6.0.0 GA +cutover, the stable rollback command is: ```bash ./scripts/install.sh --version v5.1.35 diff --git a/docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md b/docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md index a2a7f8323..86f1566d1 100644 --- a/docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md +++ b/docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md @@ -64,8 +64,8 @@ These do not qualify as v5 maintenance work: The first stable `v6.0.0` release must publish this exact notice: -> Pulse v5 entered maintenance-only support on 2026-07-03. I will ship only +> Pulse v5 entered maintenance-only support on 2026-07-04. I will ship only > critical security, data-loss, licensing or billing blocker, installer or > updater failure, and safe migration blocker fixes for existing v5 users until -> 2026-10-01. After 2026-10-01, Pulse v5 is end-of-support and new fixes land +> 2026-10-02. After 2026-10-02, Pulse v5 is end-of-support and new fixes land > on v6 unless I publish an explicit exception. diff --git a/docs/release-control/v6/internal/records/current-branch-ga-owner-approval-2026-07-02.md b/docs/release-control/v6/internal/records/current-branch-ga-owner-approval-2026-07-02.md index 3887cfc0a..67d0baddd 100644 --- a/docs/release-control/v6/internal/records/current-branch-ga-owner-approval-2026-07-02.md +++ b/docs/release-control/v6/internal/records/current-branch-ga-owner-approval-2026-07-02.md @@ -6,8 +6,8 @@ - Scope decision: include accumulated post-RC7 changes in the GA release - Additional RC or soak required: no - Additional current-branch validation required before GA: no -- GA date for publication packet: 2026-07-03 -- v5 end-of-support date for publication packet: 2026-10-01 +- GA date for publication packet: 2026-07-04 +- v5 end-of-support date for publication packet: 2026-10-02 ## Owner Direction @@ -18,7 +18,7 @@ soak cycle. This record is risk acceptance, not validation evidence. The release record must not describe the post-RC7 changes as RC-tested. The public release packet must describe v6.0.0 as the current branch GA after seven release candidates, -with the exact GA and v5 end-of-support dates updated for the actual July 3, +with the exact GA and v5 end-of-support dates updated for the actual July 4, 2026 publication. ## Release-Control Impact diff --git a/docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-07-04.md b/docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-07-04.md new file mode 100644 index 000000000..3aac945ab --- /dev/null +++ b/docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-07-04.md @@ -0,0 +1,155 @@ +# Known RC Issue Closure For GA Record + +- Date: `2026-07-04` +- Candidate: `pulse/v6-release` after the GA changelog reconciliation and + this release-metadata cleanup pass +- Prior dry run: `28683144630` (green; superseded by the final dry run for the + publish candidate) +- Gate: `known-rc-issue-closure-for-ga` +- Result: `pass` + +## Scope + +This record covers every open issue labeled `affects-6.0.0-rc.*` (`rc.2` +through `rc.6`) reviewed against the current GA branch candidate. Earlier RC +issues that were already closed under the `2026-04-21` closure record are not +re-walked here unless they have new activity. + +## Candidate Issue Disposition + +1. `#1465` (`[Bug]: 6.0rc.4 - Added 2 PBS Servers - showing error in Dashboard + but looks fine in Settings / Infrastructure`) + - Partially fixed in candidate. The dashboard-vs-settings contradiction + (defer-evaluation bug in the PBS poller) is fixed by `bf6261adc` and + `bd7d196c1`, both ancestors of `8bac64f90`. + - The remaining connection-failure portion is the reporter's separate TLS + cert-mismatch report (`#1476`), not an admitted Pulse defect. + - Disposition: fixed in candidate (Pulse-owned portion); the GitHub issue + can stay open until the reporter confirms on GA or closes it. + +2. `#1464` (`[Bug]: Failed to fetch audit events: Internal Server Error`) + - Logging gap fixed by `27bd31684` (in `8bac64f90`); the audit-list 500 + now records its underlying cause. + - Root cause of the query failure itself was never confirmed by the + reporter (suspected SQLite `database is locked` on a busy audit table). + The diagnostics improvement is in; the actual query behavior is + unverified. + - Disposition: partially fixed in candidate. Not an admitted hard GA + blocker because the handler now fails with diagnostic logging instead + of a silent 500, but the underlying slowness/lock risk on sizeable + audit tables is unresolved and should be watched post-GA. + +3. `#1496` (`[Bug]: pulseV6, unified_resources.db growing, growing,...`) + - Fixed in candidate by `3202b4ab5` (`fix: add retention pruning for + unified_resources.db (issue #1496)`) and `028e8c8df` (space reclamation + and retention for all append-only tables), both in `8bac64f90`. + - Disposition: fixed in candidate. The reporter's own diagnosis pointed + at exactly the missing retention/prune path that these commits added. + +4. `#1470` (`[Bug]: Wrong install.sh for 6.0.0 rc.1-rc.5 releases?`) + - Fix commits landed on `pulse/v6-release`: `49412357a`, `7b2cac08b`, + `a3e36d787`, `bcbec3acd`. All four are ancestors of the GA branch + candidate. + - **Release-engineering caveat:** the fix has never shipped in a published + RC release asset. The maintainer's stated condition for closing was + "until the next RC carrying the fixes is published and validated," and + the most recent user report (`dwhoban`, 2026-06-19) confirmed the + symptom still reproduced on a clean `rc.6` install. The GA candidate + is therefore the first release where the corrected `install.sh` asset + would be validated by real users. + - The stable release workflow now validates the published release asset + packet and then runs `install-sh-smoke.yml` against the just-published + GitHub Release URL before the release workflow can finish successfully. + - Disposition: fixed in branch/candidate source, with the public + release-asset path governed by the post-publish release workflow smoke. + The release must not be treated as complete unless that workflow gate + passes, because the historical failure mode (`[ERROR] Unknown option: + --url`) breaks fresh installs at the first step. + +5. `#1456` (`[Bug]: Workload shows no data on Pulse | Version: 6.0.0-rc.3`) + - Not an admitted Pulse defect. Maintainer attributed the reported + "no data" to a Proxmox 401 on the user's API token (revoked / + insufficient role / regenerated secret). The retired `/workloads` + aggregate page was replaced by platform-first pages in RC.5. + - Disposition: invalid / config-side. Not a GA blocker. + +6. `#1463` (`[Bug]: AI-Modell for Patrol unable to save and to run`) + - Largely config-side: maintainer identified three user-config errors + (wrong Ollama model name, missing provider API key, OpenRouter free + model lacking tool support). + - One UI improvement was promised to the reporter (toast that surfaces + the actual server response instead of the generic "Failed to save + advanced settings"). No commit was cited and none is present in the + candidate search. Treated as a small outstanding polish item, not a + GA blocker. + - Disposition: mostly invalid (config-side); one minor UI improvement + deferred to post-GA. + +7. `#1498` (`[Bug]: Pulse v6.0.0-rc.6 agents not updated`) + - The reporter expects agents to update to match the server "like in V5." + The v6 product path keeps server upgrade and Unified Agent upgrade as + separate operations, with agent self-update depending on agent + authentication, trusted update transport, and release signing trust. + - GA release notes and `docs/UPGRADE_v6.md` now state explicitly that + moving the server to v6 does not itself upgrade installed agents, and + that operators should use `Settings → Infrastructure → Install on a host` + to generate each agent install/upgrade command and verify the reported + agent version. + - Disposition: documented intentional v6 upgrade boundary, not a silent + GA blocker. The GitHub issue still needs a maintainer response so the + reporter has the same answer publicly. + +8. `#1493` (`[Bug]: Settings->infrastructure: Strange Error and API`) + - Untriaged — zero maintainer comments on the issue. Reporter sees a + stale error message and stale IP addresses on the infrastructure + settings surface after their Proxmox cluster moved subnets + (`10.32.21.x/24` to `10.32.20.x/22`). Also flags an "API" labeling + concern where the surface lists per-node entries when one cluster-wide + API token is in use. + - No fix commit identified. Reads as a display / state-staleness bug, + not a data-loss or upgrade-blocking defect. + - Disposition: unresolved, low-severity. Not a GA blocker on its face, + but genuinely unreviewed and should get a maintainer response before + GA so it is not carried silently. + +9. `#1485` (`[Bug]: Not urgent - Unraid parity alert`) + - Untriaged — zero maintainer comments. Reporter says Pulse keeps + alerting about an Unraid parity check that was cancelled on the host. + Reads as an alert-state-clearing bug specific to Unraid's parity-check + signal. No fix commit identified. + - Disposition: unresolved, low-severity (Unraid-specific, reporter + self-tagged "Not urgent"). Not a GA blocker, but should get a + maintainer response. + +10. `#1441` (`[Bug]: Server offline, shown as online`) + - Untriaged by the maintainer on this issue. A second reporter + (`asm-ch`) linked it to discussion `#1135` from 2026-01-21 and + stated it has reproduced since `v5.0.17`. This is therefore a + pre-existing v5-era Proxmox offline-state detection issue, not a + v6 regression. + - Disposition: pre-existing v5-era defect, not a v6 GA regression. + Not a GA blocker, but a two-month-old customer-trust item that + should not be carried into GA without a response. + +## Outcome + +- The RC-era issue set that received engineering attention is closed on the + candidate: PBS dashboard contradiction (`#1465`), unified_resources + retention (`#1496`), installer asset identity (`#1470` at the source + level), and audit-list diagnostics (`#1464`). +- `known-rc-issue-closure-for-ga` is satisfied for the candidate source and + GA documentation. The `#1470` public asset path remains guarded by the + release workflow's post-publish `install-sh-smoke.yml` gate; the release + must not be treated as complete if that gate fails. +- `#1498` is no longer carried silently: the GA release notes and upgrade + guide state that server upgrade and Unified Agent upgrade are separate v6 + operations, and operators must verify agent versions after running the + generated agent install/upgrade command. +- Three issues (`#1493`, `#1485`, `#1441`) are not GA blockers on their + face but are unresponded and should not be carried into GA silently. + They need a maintainer reply, even if only to set post-GA expectation. +- The 2026-04-21 closure record's convention that "GitHub issues may remain + open until public maintainer triage catches up" still holds here: this + record passing does not require every referenced GitHub issue to be + closed, only that each has been examined and given an explicit + disposition. diff --git a/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md b/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md index c37916c79..3538d6946 100644 --- a/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md +++ b/docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md @@ -8,21 +8,24 @@ 1. The latest shipped Pulse v6 prerelease tag is `v6.0.0-rc.7`. 2. That shipped prerelease tag resolves to commit `2900e41b2db95561471d17bb9f4fdf097b56b8ac`. -3. The governed release profile in `docs/release-control/control_plane.json` +3. The selected remote ref `origin/pulse/v6-release` is still behind the current + local governed branch state, so `Release Dry Run` would exercise stale remote + control-plane metadata instead of the intended candidate. +4. The governed release profile in `docs/release-control/control_plane.json` currently declares both `prerelease_branch` and `stable_branch` as `pulse/v6-release`. -4. The active control-plane target is `v6-ga-promotion`, so stable or GA +5. The active control-plane target is `v6-ga-promotion`, so stable or GA promotion is now the governed objective for Pulse v6. -5. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0`, so a +6. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0`, so a local GA candidate exists on the governed stable line. -6. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful +7. There is still no governed `Prerelease-to-GA Rehearsal Record` proving a successful non-publish `Release Dry Run` for the current `6.0.0` candidate. -7. `docs/releases/RELEASE_NOTES_v6.md` and +8. `docs/releases/RELEASE_NOTES_v6.md` and `docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md` now carry the currently proposed exact dates for the eventual GA notice: - - `v6` GA date: `2026-07-03` - - `v5` end-of-support date: `2026-10-01` -8. There is still no governed `Release Dry Run` artifact or rehearsal record + - `v6` GA date: `2026-07-04` + - `v5` end-of-support date: `2026-10-02` +9. There is still no governed `Release Dry Run` artifact or rehearsal record exercising stable inputs for: - `version=6.0.0` - `promoted_from_tag=v6.0.0-rc.7` @@ -30,10 +33,10 @@ - the artifact-owned promotion channel for that rehearsal - the artifact-owned promoted prerelease tag for that rehearsal - the artifact-owned rollback target for that stable candidate - - `ga_date=2026-07-03` + - `ga_date=2026-07-04` - an explicit `rollback_version` - the exact derived rollback command that artifact will publish - - `v5_eos_date=2026-10-01` + - `v5_eos_date=2026-10-02` ## Why The Gate Cannot Be Cleared Yet @@ -54,10 +57,10 @@ users would still be the first real cohort for the final promotion path. - an artifact-owned promoted prerelease tag matching that rehearsal - an artifact-owned rollback target for the stable candidate - the exact planned GA and v5 end-of-support dates for the publish notice - - `ga_date=2026-07-03` + - `ga_date=2026-07-04` - an explicit stable `rollback_version` - the exact derived rollback command that artifact will publish - - `v5_eos_date=2026-10-01` + - `v5_eos_date=2026-10-02` 3. Capture the `rc-to-ga-rehearsal-summary` artifact and run URL. 4. Materialize the final rehearsal record from that artifact without hand-repairing any missing candidate tag, promoted prerelease tag, rollback diff --git a/docs/release-control/v6/internal/subsystems/deployment-installability.md b/docs/release-control/v6/internal/subsystems/deployment-installability.md index ec1a97099..6ed89521a 100644 --- a/docs/release-control/v6/internal/subsystems/deployment-installability.md +++ b/docs/release-control/v6/internal/subsystems/deployment-installability.md @@ -588,9 +588,9 @@ TLS floor in the dynamic config. rollback target, exact GA date, and exact v5 end-of-support date aligned across release notes, upgrade guidance, support policy, promotion records, and release-promotion resolver proof before workflow dispatch. For the - 2026-07-03 cutover candidate, that packet is + 2026-07-04 cutover candidate, that packet is `promoted_from_tag=v6.0.0-rc.7`, `rollback_version=v5.1.35`, - `ga_date=2026-07-03`, and `v5_eos_date=2026-10-01`. + `ga_date=2026-07-04`, and `v5_eos_date=2026-10-02`. That stable cut must also move the repo-root Docker compose default and `scripts/install-docker.sh` fallback from the final RC image tag to the stable `6.0.0` image tag in the same commit as `VERSION=6.0.0`. @@ -761,7 +761,7 @@ The active stable `v6.0.0` cut sets the repo-root `VERSION`, repo-root `docker-compose.yml` image default, and `scripts/install-docker.sh` fallback to the same `6.0.0` release version. The GA promotion metadata for this cut is `promoted_from_tag=v6.0.0-rc.7`, `rollback_version=v5.1.35`, -`ga_date=2026-07-03`, and `v5_eos_date=2026-10-01`. +`ga_date=2026-07-04`, and `v5_eos_date=2026-10-02`. The shell-installer boundary carries root-agent service hardening for Linux installs. Installer-rendered agent units must keep the health/metrics listener diff --git a/docs/releases/RELEASE_NOTES_v6.md b/docs/releases/RELEASE_NOTES_v6.md index 14590f858..5412b3e9c 100644 --- a/docs/releases/RELEASE_NOTES_v6.md +++ b/docs/releases/RELEASE_NOTES_v6.md @@ -23,10 +23,10 @@ already know. ## Pulse v5 Support Transition -Pulse v5 entered maintenance-only support on `2026-07-03`. +Pulse v5 entered maintenance-only support on `2026-07-04`. I will ship only critical security, data-loss, licensing or billing blocker, -installer or updater failure, and safe migration blocker fixes for existing v5 users until `2026-10-01`. -After `2026-10-01`, Pulse v5 is end-of-support and new fixes land on v6 unless +installer or updater failure, and safe migration blocker fixes for existing v5 users until `2026-10-02`. +After `2026-10-02`, Pulse v5 is end-of-support and new fixes land on v6 unless I publish an explicit exception. ## What Is In v6.0.0 @@ -139,8 +139,11 @@ hosted product; see the MSP section of the pricing doc. 4. Re-test recovery workflows and any backup-era assumptions. 5. Verify license activation or paid-license migration immediately after first boot on upgraded systems. -6. Upgrade Unified Agents separately only when you are explicitly testing the - v5-to-v6 agent path. +6. Upgrade Unified Agents separately from the server. Moving the Pulse server + to v6 does not by itself upgrade installed agents; after the server upgrade, + use `Settings → Infrastructure → Install on a host` to generate the current + install or upgrade command for each agent host, then confirm each agent + reports its v6 version. ## Operator References diff --git a/scripts/release_control/release_promotion_policy_test.py b/scripts/release_control/release_promotion_policy_test.py index ee5a85914..72f85eaa1 100644 --- a/scripts/release_control/release_promotion_policy_test.py +++ b/scripts/release_control/release_promotion_policy_test.py @@ -162,10 +162,10 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn("current `pulse/v6-release` branch", normalized_release_notes) self.assertIn("seven release candidates and accumulated post-RC7 fixes", normalized_release_notes) - self.assertIn("Pulse v5 entered maintenance-only support on `2026-07-03`.", normalized_release_notes) - self.assertIn("existing v5 users until `2026-10-01`.", normalized_release_notes) - self.assertIn("Pulse v5 entered maintenance-only support on 2026-07-03.", normalized_v5_policy) - self.assertIn("2026-10-01. After 2026-10-01", normalized_v5_policy) + self.assertIn("Pulse v5 entered maintenance-only support on `2026-07-04`.", normalized_release_notes) + self.assertIn("existing v5 users until `2026-10-02`.", normalized_release_notes) + self.assertIn("Pulse v5 entered maintenance-only support on 2026-07-04.", normalized_v5_policy) + self.assertIn("2026-10-02. After 2026-10-02", normalized_v5_policy) gate = next(gate for gate in status["release_gates"] if gate["id"] == "rc-to-ga-promotion-readiness") self.assertEqual(gate["status"], "passed") diff --git a/scripts/release_control/resolve_release_promotion_test.py b/scripts/release_control/resolve_release_promotion_test.py index bd8e18d95..d41cfee70 100644 --- a/scripts/release_control/resolve_release_promotion_test.py +++ b/scripts/release_control/resolve_release_promotion_test.py @@ -92,8 +92,8 @@ class ResolveReleasePromotionTest(unittest.TestCase): version="6.0.0", promoted_from_tag_input="v6.0.0-rc.7", rollback_version_input="v5.1.35", - ga_date_input="2026-07-03", - v5_eos_date_input="2026-10-01", + ga_date_input="2026-07-04", + v5_eos_date_input="2026-10-02", hotfix_exception=False, hotfix_reason_input="", release_notes_input=release_notes, @@ -107,8 +107,8 @@ class ResolveReleasePromotionTest(unittest.TestCase): self.assertEqual(metadata["promoted_from_tag"], "v6.0.0-rc.7") self.assertEqual(metadata["rollback_tag"], "v5.1.35") self.assertEqual(metadata["rollback_command"], "./scripts/install.sh --version v5.1.35") - self.assertEqual(metadata["ga_date"], "2026-07-03") - self.assertEqual(metadata["v5_eos_date"], "2026-10-01") + self.assertEqual(metadata["ga_date"], "2026-07-04") + self.assertEqual(metadata["v5_eos_date"], "2026-10-02") def test_stable_hotfix_requires_reason(self) -> None: with self.assertRaisesRegex(ValueError, "hotfix_reason is required"):