From 2c3ece3e519afeb3c743b45f14ae6b1aa5dffc58 Mon Sep 17 00:00:00 2001 From: rcourtman Date: Fri, 1 May 2026 20:25:19 +0100 Subject: [PATCH] Prepare v6.0.0-rc.3 release packet --- VERSION | 2 +- docs/RELEASE_NOTES.md | 7 +- docs/UPGRADE_v6.md | 6 + ...legacy-cleanup-v6-rc3-packet-2026-05-01.md | 73 ++++++++ ...-promotion-readiness-blocked-2026-04-04.md | 17 +- docs/release-control/v6/internal/status.json | 6 + .../subsystems/deployment-installability.md | 4 + docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md | 160 ++++++++++++++++ docs/releases/V6_CHANGELOG_RC3_DRAFT.md | 120 ++++++++++++ docs/releases/V6_PRERELEASE_RUNBOOK.md | 4 +- .../V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md | 175 ++++++++++++++++++ .../documentation_currentness_test.py | 3 + .../release_promotion_policy_test.py | 30 ++- .../render_release_body_test.py | 3 + 14 files changed, 593 insertions(+), 17 deletions(-) create mode 100644 docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-v6-rc3-packet-2026-05-01.md create mode 100644 docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md create mode 100644 docs/releases/V6_CHANGELOG_RC3_DRAFT.md create mode 100644 docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md diff --git a/VERSION b/VERSION index 09b254e90c..ee4f7b3749 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -6.0.0 +6.0.0-rc.3 diff --git a/docs/RELEASE_NOTES.md b/docs/RELEASE_NOTES.md index 2047bf6f1e..1addd203a6 100644 --- a/docs/RELEASE_NOTES.md +++ b/docs/RELEASE_NOTES.md @@ -16,7 +16,12 @@ For the historical shipped v6 `rc.1` packet, see: - `docs/releases/V6_CHANGELOG_RC1.md` - `docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md` -For the final in-repo v6 `rc.2` draft packet, see: +For the current in-repo v6 `rc.3` draft packet, see: +- `docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md` +- `docs/releases/V6_CHANGELOG_RC3_DRAFT.md` +- `docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md` + +For the historical in-repo v6 `rc.2` draft packet, see: - `docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md` - `docs/releases/V6_CHANGELOG_RC2_DRAFT.md` - `docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md` diff --git a/docs/UPGRADE_v6.md b/docs/UPGRADE_v6.md index 99db7292f0..cb69203368 100644 --- a/docs/UPGRADE_v6.md +++ b/docs/UPGRADE_v6.md @@ -7,6 +7,12 @@ For current stable release notes and rollout references, see: - `docs/releases/RELEASE_NOTES_v6.md` - `docs/releases/V6_CHANGELOG.md` +For the current v6 prerelease packet, see: + +- `docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md` +- `docs/releases/V6_CHANGELOG_RC3_DRAFT.md` +- `docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md` + ## Before You Upgrade - Create an encrypted config backup: **Settings → System → Recovery → Create Backup** (older versions labeled this **Backups**) diff --git a/docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-v6-rc3-packet-2026-05-01.md b/docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-v6-rc3-packet-2026-05-01.md new file mode 100644 index 0000000000..3e6b3b2a6f --- /dev/null +++ b/docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-v6-rc3-packet-2026-05-01.md @@ -0,0 +1,73 @@ +# Documentation Currentness And Legacy Cleanup v6 RC3 Packet Record + +- Date: `2026-05-01` +- Gate: `documentation-currentness-and-legacy-cleanup` +- Scope: + - `pulse` + - lane `L9` + +## Context + +The late RC3 audit compared recent v5.1.29 maintenance fixes, open GitHub +issues, and v6 release-branch evidence. The branch now needs a current RC3 +packet so operator guidance matches the candidate being prepared instead of +leaving the top-level release note pointer on the older RC2 draft. + +## Review Surface + +1. `VERSION` +2. `docs/RELEASE_NOTES.md` +3. `docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md` +4. `docs/releases/V6_CHANGELOG_RC3_DRAFT.md` +5. `docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md` +6. `docs/releases/V6_PRERELEASE_RUNBOOK.md` +7. `docs/UPGRADE_v6.md` +8. `docs/release-control/v6/internal/subsystems/deployment-installability.md` +9. `docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md` +10. `.github/workflows/create-release.yml` +11. `scripts/release_control/resolve_release_promotion.py` +12. `scripts/release_control/release_promotion_policy_test.py` + +## Outcome + +The in-repo release packet now reflects the current `v6.0.0-rc.3` candidate: + +- `VERSION` is set to `6.0.0-rc.3`, matching the release workflow version + preflight requirement. +- `docs/RELEASE_NOTES.md` points current v6 prerelease readers at the RC3 + packet while keeping the RC2 draft as historical context. +- The RC3 release notes, changelog, and operator support pack describe the + late v5.1.29 maintenance ports, the current RC issue fixes, and the areas + operators should re-test. +- The packet records `v5.1.29` as the stable rollback target with + `./scripts/install.sh --version v5.1.29`. +- The packet explicitly warns that systems pinned to the historical `rc.2` + update trust root should use manual reinstall or explicit trust migration + rather than assuming unattended continuity into later prerelease or GA builds. +- `docs/UPGRADE_v6.md` and the prerelease runbook now point current prerelease + operators at the RC3 packet instead of leaving the proof surface on RC2. +- The deployment-installability contract records that later corrective RC + packets must carry the live rollback target and any trust-root continuity + caveat before the release workflow is dispatched. +- The RC-to-GA blocked record now reflects that the current line is preparing + `VERSION=6.0.0-rc.3`, not a `6.0.0` GA candidate. + +No GitHub release, public issue comment, retitle, closure, or other external +state change was made as part of this packet preparation. + +## Proof + +- `python3 scripts/release_control/status_audit.py --pretty` + - `repo_ready=True` + - `rc_ready=True` + - `release_ready=True` + - `current_version=6.0.0-rc.3` +- `python3 scripts/release_control/documentation_currentness_test.py` + - passed, 6 tests +- `python3 scripts/release_control/release_promotion_policy_test.py` + - passed, 17 tests +- `python3 scripts/release_control/render_release_body_test.py` + - passed, 3 tests +- `python3 scripts/release_control/resolve_release_promotion.py --version 6.0.0-rc.3 --rollback-version v5.1.29` + - `rollback_tag=v5.1.29` + - `rollback_command=./scripts/install.sh --version v5.1.29` 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 5dd10a15f9..7959f8a27f 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 @@ -16,10 +16,11 @@ `pulse/v6-release`. 5. The active control-plane target is still `v6-product-lane-expansion`, not `v6-ga-promotion`. -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. The active local `pulse/v6-release` branch currently reports `VERSION=6.0.0-rc.3`, so the + working line is still prerelease and there is not yet a governed local stable + `6.0.0` candidate. 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. + non-publish `Release Dry Run` for the eventual stable `6.0.0` candidate. 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: @@ -41,8 +42,9 @@ ## Why The Gate Cannot Be Cleared Yet The blocker is no longer missing governance text. The remaining problem is that -the control plane still holds v6 on the pre-GA prerelease line, and there is -still no exercised `Release Dry Run` record proving the exact `6.0.0` +the control plane still holds v6 on the pre-GA prerelease line, the working +version is still prerelease (`6.0.0-rc.3`), and there is still no exercised +`Release Dry Run` record proving the eventual stable `6.0.0` candidate is ready for GA-style promotion. Until that rehearsal exists, stable users would still be the first real cohort for the final promotion path. @@ -50,8 +52,9 @@ users would still be the first real cohort for the final promotion path. 1. Promote the active target from `v6-product-lane-expansion` to `v6-ga-promotion` only when that change is actually intended. -2. Push the governed `pulse/v6-release` branch state, including the current - `VERSION=6.0.0` candidate and release-control records, to `origin/pulse/v6-release`. +2. Push the governed `pulse/v6-release` branch state that is intended to become the + stable `6.0.0` candidate, including the eventual `VERSION=6.0.0` + change and release-control records, to `origin/pulse/v6-release`. 3. Run `Release Dry Run` from `pulse/v6-release` with: - `version=6.0.0` - `promoted_from_tag=v6.0.0-rc.2` diff --git a/docs/release-control/v6/internal/status.json b/docs/release-control/v6/internal/status.json index f4b3bdbeab..81846e1b38 100644 --- a/docs/release-control/v6/internal/status.json +++ b/docs/release-control/v6/internal/status.json @@ -4327,6 +4327,12 @@ "path": "docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-contribution-policy-2026-05-01.md", "kind": "file", "evidence_tier": "local-rehearsal" + }, + { + "repo": "pulse", + "path": "docs/release-control/v6/internal/records/documentation-currentness-and-legacy-cleanup-v6-rc3-packet-2026-05-01.md", + "kind": "file", + "evidence_tier": "local-rehearsal" } ] }, diff --git a/docs/release-control/v6/internal/subsystems/deployment-installability.md b/docs/release-control/v6/internal/subsystems/deployment-installability.md index b917ae0df6..5d18177e8b 100644 --- a/docs/release-control/v6/internal/subsystems/deployment-installability.md +++ b/docs/release-control/v6/internal/subsystems/deployment-installability.md @@ -164,6 +164,10 @@ server-side update execution surfaces. operator support packet must describe that same candidate instead of leaving the branch on a newer version string while the in-repo packet still speaks for an older RC. + Later corrective RCs such as `rc.3` must also carry the live stable + rollback target and any prerelease trust-root continuity caveat in the + current release notes, changelog, operator support pack, upgrade guide, and + release-control evidence record before the release workflow is dispatched. The prerelease feedback intake template and active demo/update metadata must also stay on generic or current-RC wording instead of hard-coding stale `rc.1` examples once later candidates exist. diff --git a/docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md b/docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md new file mode 100644 index 0000000000..6c4072c421 --- /dev/null +++ b/docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md @@ -0,0 +1,160 @@ +# Pulse v6.0.0-rc.3 Draft Release Notes + +_Draft only. Do not treat this as published until the governed +`v6.0.0-rc.3` tag and GitHub prerelease exist._ + +`v6.0.0-rc.3` is intended to be the second corrective RC after the public +`rc.1` release and the first candidate after the `v5.1.29` maintenance sweep. +Pulse v5.1.29 remains the current stable line. + +The purpose of this RC is to carry late v5 maintenance fixes and recent RC +feedback into the v6 candidate before broader retesting: + +- v5-to-v6 installs and updates should avoid avoidable installer, disk-space, + token-display, and rollback surprises +- agent identity and reconnect behavior should remain stable across Docker LXC, + recreated containers, and Proxmox setup-script paths +- alert, backup, snapshot, and storage views should not regress from the + current v5 maintenance line +- Workloads, Storage, and Infrastructure should be retestable with the current + table-first and responsive UI corrections +- the support packet should be explicit about the post-`rc.2` update-signer + transition and the stable rollback target + +## Support Stance + +- Pulse v5.1.29 remains the current stable line. +- Pulse v6 `rc.3` is still an opt-in evaluation build, not the default + production recommendation. +- Existing v5 users should still prefer staging, lab, or otherwise controlled + evaluation first. +- Hosts already pinned to the historical `rc.2` update trust root should not + assume unattended auto-update continuity into later prerelease or GA builds. + Use a manual reinstall or an explicit trust migration path for `rc.3`. +- The stable rollback target for this candidate is `v5.1.29`: + `./scripts/install.sh --version v5.1.29` + +## What Changed Since `rc.2` + +### Installer And Update Continuity + +- The stable install path remains anchored to v5.1.29 instead of accidentally + resolving to a v6 RC from the fresh Proxmox LXC script path. +- The installer now checks available disk space before stopping the current + service, so a low-space update should fail before interrupting a working + install. +- The installer bundle fallback no longer depends on an external helper being + available at the point where the fallback is needed. +- Bootstrap-token display now uses the supported `pulse bootstrap-token` + command path instead of surfacing encrypted `.bootstrap_token` JSON. +- The update-progress modal remains dismissible after an update completes or + fails. +- The release packet records `v5.1.29` as the governed rollback target for + `rc.3`. + +### Agent Identity, Reconnect, And Host Setup + +- Docker agents running inside Proxmox LXC keep the canonical host identity and + reconnect token binding after agent restarts or container recreation. +- The v5-to-v6 server and agent continuity path keeps stable identity files + and avoids avoidable duplicate-host behavior. +- Proxmox setup scripts preserve existing `authorized_keys` symlinks instead + of replacing the symlink target with a regular file. +- Agent privilege expectations are documented for RC testing, including why the + current agent still needs the documented local privileges. +- Patrol local discovery probes are aligned with the agent command policy. + +### Alerts, Backup, Snapshot, And Storage Correctness + +- Disabled alert notification channels no longer continue sending cooldown + reminders after the user turns notification delivery off. +- Docker update-alert disable cleanup and alert-threshold metric coloring match + the configured alert state. +- PBS threshold handling is corrected for the recent v5 maintenance feedback. +- Backup orphan/template readiness and recovery inventory handling now avoid + stale or missing-state regressions. +- Synology RAID scrub activity is gated on mdstat operation state so normal + scrubs are less likely to look like unexpected rebuild alerts. +- Ceph monitor count handling uses monitor arrays where available. +- Proxmox snapshots are preserved for guests that are temporarily missed by a + poll. +- PBS and host-linked ZFS filesystems merge into guest overviews where the host + relationship is known. + +### Monitoring History, AI, And Runtime Behavior + +- Duplicate metrics are handled idempotently instead of creating noisy history + rows. +- Local Ollama calls use a shorter keep-alive window so test systems are less + likely to hold local model resources longer than needed. +- Backup, recovery, and inventory guardrails were rechecked against the late + RC3 issue sweep. + +### Workloads, Storage, And Infrastructure UI + +- Workloads, Storage, and Infrastructure keep the current table-first layout, + filter deck, saved-view, chart-toggle, and responsive wrapping fixes from the + v6 release branch. +- On narrow/mobile Workloads views, summary charts stay out of the primary + table flow so the table remains usable. +- Summary-chart hover tooltips now offset from the guide line instead of + covering the exact value under the cursor. + +### Security And Public Feedback Flow + +- Frontend sanitization and Go network dependencies are current for this + release branch. +- Public contribution guidance now steers unsolicited work through issues and + discussions first while keeping the dedicated v6 RC feedback path available. +- The late open issue and discussion pass did not identify another unhandled + narrow RC3 code blocker in the current candidate. + +### Paid-Plan Wording Stays On The `rc.2` Model + +`rc.3` does not reopen the self-hosted paid model settled in `rc.2`. Relay is +still described as secure remote access to the Pulse web UI, +Pulse Mobile pairing for handoff, push notifications, and 14-day history. Pro +remains Relay plus AI operations, automation, advanced admin features, and +90-day history. + +## What Existing v5 Users Should Re-Test In `rc.3` + +1. Server upgrade from the current v5 stable line to v6, including the manual + or explicit trust-migration path needed for builds after `rc.2`. +2. Fresh Proxmox LXC install and rollback to v5.1.29. +3. Docker Unified Agent inside LXC after restart and container recreation. +4. Alert notification settings, cooldown behavior, PBS thresholds, Docker + update alerts, and configured alert-threshold colors. +5. Backup, snapshot, recovery, and storage views, including Proxmox snapshots + and PBS/ZFS filesystem attribution. +6. Workloads, Storage, and Infrastructure table layouts at desktop and mobile + sizes, including summary-chart hover behavior. +7. AI/Patrol local discovery and Ollama-backed flows if those features are in + use. + +## Feedback + +Use the `Pulse v6 pre-release feedback` issue template for regressions, upgrade +failures, licensing continuity problems, platform-specific breakage, or +actionable UX friction: + +- `https://github.com/rcourtman/Pulse/issues/new?template=v6_rc_feedback.yml` + +When reporting an `rc.3` problem, include: + +- Pulse version +- upgrade path or fresh-install path +- installation type +- whether the host was previously on `rc.1`, `rc.2`, or v5 +- whether a manual reinstall or trust migration was used after `rc.2` +- what you expected +- what happened instead +- sanitized logs, screenshots, or diagnostics when helpful + +## Operator References + +- `docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md` +- `docs/releases/V6_CHANGELOG_RC3_DRAFT.md` +- `docs/UPGRADE_v6.md` +- `docs/AGENT_SECURITY.md` +- `docs/MIGRATION_UNIFIED_NAV.md` diff --git a/docs/releases/V6_CHANGELOG_RC3_DRAFT.md b/docs/releases/V6_CHANGELOG_RC3_DRAFT.md new file mode 100644 index 0000000000..7d990f0722 --- /dev/null +++ b/docs/releases/V6_CHANGELOG_RC3_DRAFT.md @@ -0,0 +1,120 @@ +# Pulse v6.0.0-rc.3 Draft Changelog + +_Draft only. This changelog describes the current `pulse/v6-release` delta +since the planned `v6.0.0-rc.2` candidate. Do not treat it as published until +the governed `v6.0.0-rc.3` prerelease exists._ + +## What `rc.3` changes compared with `rc.2` + +`v6.0.0-rc.3` is a corrective maintenance RC. It carries the late v5.1.29 +maintenance sweep and the current RC feedback fixes into the v6 release branch +without reopening the product model that `rc.2` settled. + +The main release risk addressed here is regression drift: fixes that users +already received on the v5 stable line should not disappear when they evaluate +v6. + +## Major Changes + +### 1. Installer and rollback behavior is safer for RC retesting + +The release branch now keeps the stable install/update path anchored to +v5.1.29 while preparing the `rc.3` prerelease packet. + +The installer changes in this candidate include: + +- Proxmox LXC stable installs do not accidentally fall through to a v6 RC +- low-disk updates fail before stopping the current service +- installer bundle fallback logic works without relying on a missing external + helper +- bootstrap-token display uses the supported `pulse bootstrap-token` path +- update progress remains closable +- the governed rollback command for this candidate is + `./scripts/install.sh --version v5.1.29` + +There is also an important prerelease update note: systems pinned to the +historical `rc.2` update trust root should use a manual reinstall or explicit +trust migration for later prerelease and GA builds. Do not assume unattended +`rc.2` to `rc.3` continuity. + +### 2. Agent identity and setup paths are less fragile + +`rc.3` carries the v5/v6 agent continuity corrections from the late issue +sweep: + +- Docker agents inside Proxmox LXC preserve their canonical host identity and + reconnect token binding after restart or recreated container flows +- v5-to-v6 agent identity files remain stable instead of creating avoidable + duplicate hosts +- Proxmox setup scripts preserve existing `authorized_keys` symlinks +- the agent privilege model is documented for operators +- Patrol discovery probes align with the agent command policy + +### 3. Alerts, recovery, and storage views match late v5 fixes + +The candidate includes the alert and recovery correctness fixes from the +maintenance audit: + +- disabled notification channels stop sending alert cooldown reminders +- Docker update-alert disable cleanup is retained +- alert-threshold colors respect configured thresholds +- PBS threshold behavior is corrected +- backup orphan/template readiness is guarded +- Synology mdstat operation state gates RAID rebuild alerts during scrubs +- Ceph monitor counts come from monitor arrays where available +- Proxmox snapshots are preserved across transient poll misses +- host-linked PBS/ZFS filesystems merge into guest overviews where ownership is + known + +### 4. Runtime history and AI behavior are quieter + +The duplicate-metrics path is idempotent, reducing noisy historical rows during +polling overlap. Local Ollama-backed AI calls also use a shorter keep-alive +window so evaluation systems are less likely to retain model resources +unnecessarily. + +### 5. Workloads, Storage, and Infrastructure are ready for another UI pass + +The current branch keeps the table-first v6 operational UI corrections: + +- Workloads, Storage, and Infrastructure have the current filter, saved-view, + table, chart-toggle, and responsive wrapping fixes +- narrow Workloads layouts keep charts out of the primary mobile table flow +- summary-chart hover tooltips now offset away from the guide line instead of + covering the value being inspected + +### 6. Security dependencies and contribution guidance are current + +The frontend sanitizer and Go network dependency updates are present on the +release branch. Public contribution guidance now matches the issue-first +policy for the current RC cycle while preserving the dedicated v6 feedback +template. + +The self-hosted paid wording remains aligned with `rc.2`: Relay is secure +remote access to the Pulse web UI, Pulse Mobile pairing for handoff, push +notifications, and 14-day history, while Pro adds AI operations, automation, +advanced admin features, and 90-day history. + +## What existing v5 users should re-test in `rc.3` + +1. v5.1.29 to v6 server upgrade and rollback to v5.1.29. +2. The explicit post-`rc.2` trust migration or manual reinstall path. +3. Docker Unified Agent in Proxmox LXC after agent restart and container + recreation. +4. Alert notification disablement, cooldown behavior, thresholds, and PBS/Docker + alert paths. +5. Backup, snapshot, recovery, PBS, ZFS, Synology RAID, and Ceph inventory + views. +6. Workloads, Storage, and Infrastructure at desktop and mobile sizes. +7. AI/Patrol local discovery and Ollama-backed flows where enabled. + +## Evidence Appendix + +For the code-backed evidence packet that maps these claims to the current +release line, see: + +- `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-blocked-2026-05-01.md` +- `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-rc3-followup-2026-05-01.md` +- `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-v5-129-delta-2026-05-01.md` +- `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-late-issue-intake-2026-05-01.md` +- `docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-summary-sparkline-tooltip-2026-05-01.md` diff --git a/docs/releases/V6_PRERELEASE_RUNBOOK.md b/docs/releases/V6_PRERELEASE_RUNBOOK.md index e21d05cf2e..6e0eadbc72 100644 --- a/docs/releases/V6_PRERELEASE_RUNBOOK.md +++ b/docs/releases/V6_PRERELEASE_RUNBOOK.md @@ -63,7 +63,7 @@ artifacts, or to an explicitly verified paid container image, rather than the pu ## Versioning Rules - v5 stable examples: `5.1.14` -- v6 prerelease examples: `6.0.0-rc.1`, `6.0.0-rc.2` +- v6 prerelease examples: `6.0.0-rc.1`, `6.0.0-rc.2`, `6.0.0-rc.3` - v6 GA example: `6.0.0` The workflow auto-marks `-rc.N`/`-alpha.N`/`-beta.N` as prerelease. @@ -93,7 +93,7 @@ The workflow auto-marks `-rc.N`/`-alpha.N`/`-beta.N` as prerelease. 1. Update version on `pulse/v6-release`: ```bash -export RC_VERSION="6.0.0-rc.2" +export RC_VERSION="6.0.0-rc.3" git checkout pulse/v6-release git pull --ff-only diff --git a/docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md b/docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md new file mode 100644 index 0000000000..fb0ebea182 --- /dev/null +++ b/docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md @@ -0,0 +1,175 @@ +# Pulse v6 RC3 Draft Operator Support Pack + +_Draft only. Use this as the working support brief for the planned +`v6.0.0-rc.3` candidate until the final prerelease notes are published._ + +## Support Stance + +- Pulse v5.1.29 remains the current stable line. +- Pulse v6 `rc.3` is an opt-in evaluation build, not the default production + recommendation. +- `rc.3` should be described as a corrective maintenance RC: it carries late v5 + maintenance fixes and current RC feedback into the v6 candidate before + broader retesting. +- Systems pinned to the historical `rc.2` update trust root should use a manual + reinstall or explicit trust migration for later prerelease or GA builds. + +## Short Answers + +### Is `rc.3` the stable release? + +No. The current stable release is v5.1.29. `rc.3` is still a v6 prerelease for +controlled evaluation. + +### Should production v5 users upgrade immediately? + +No. The recommended RC posture is still staging, lab, or controlled evaluation +first. + +### What is the rollback target? + +Use v5.1.29: + +`./scripts/install.sh --version v5.1.29` + +### Can `rc.2` systems auto-update directly to `rc.3`? + +Do not promise unattended continuity from `rc.2` to `rc.3`. Hosts pinned to the +historical `rc.2` update trust root need a manual reinstall or explicit trust +migration path for later prerelease or GA builds. + +### Does self-hosted v6 still cap monitored systems? + +No for the current public self-hosted plans. Community, Relay, and Pro include +core self-hosted monitoring by default, as described in the `rc.2` support +packet. + +Current plan shorthand: + +- Community: + core monitoring included, 7-day history +- Relay: + core monitoring included, secure remote access to the Pulse web UI, + Pulse Mobile pairing for handoff, push notifications, and 14-day history +- Pro: + Relay plus AI operations, automation, advanced admin features, and 90-day + history + +### What happens to existing paid Pulse Pro customers in v6? + +Use this cohort breakdown: + +- Legacy recurring monthly or annual subscribers from v5 or earlier who were + already active before the public v6 pricing cutover: + keep the current recurring price, with self-hosted monitoring and + child-resource volume not metered while the subscription remains continuously + active under the current v6 policy. +- Existing lifetime customers: + remain permanently valid, with self-hosted monitoring and child-resource + volume not metered under the current v6 policy. +- Legacy paid v5 licenses migrated into v6 outside the recurring grandfathered + path: + can still exchange into the v6 activation model without repurchasing. +- Former recurring subscribers who already canceled or later lapse: + any later return uses current public v6 pricing rather than resuming the old + grandfathered terms. + +### What changed from `rc.2` that users should notice immediately? + +- stable install paths stay on v5.1.29 unless the user explicitly opts into v6 +- installer disk preflight runs before stopping the current service +- bootstrap-token display uses the supported command path +- Docker agents in Proxmox LXC keep host identity after restart/recreation +- alert notification disablement, thresholds, and PBS/Docker alert paths are + corrected +- backup, snapshot, and linked filesystem views carry the late v5 fixes +- Workloads summary-chart tooltips no longer cover the guide line + +### What if a fresh Proxmox LXC stable install lands on a v6 RC? + +Treat that as a release-blocking install regression. The stable path should +resolve to v5.1.29 unless the user intentionally chose a v6 prerelease. + +### What if a bootstrap-token command shows encrypted JSON? + +Treat that as a bug. Operators should use the supported `pulse bootstrap-token` +command path, and the installer/support flow should not ask them to decode the +encrypted `.bootstrap_token` file. + +### What if a Docker agent duplicates or loses identity after recreation? + +Collect logs and escalate. `rc.3` includes the canonical reconnect-token and +host-identity binding fix for Docker agents inside Proxmox LXC. + +### What if alert behavior still looks wrong? + +Ask for the alert rule, delivery-channel state, threshold values, current Pulse +version, and screenshots or logs. `rc.3` includes fixes for disabled +notification cooldowns, Docker update-alert disable cleanup, configured +threshold colors, and PBS threshold handling. + +### What if issue `#1451` still reports a restore error after `rc.3`? + +Check whether the host still has the stale legacy +`/run/pulse-sensor-proxy` LXC mount from an old install path. The token-format +part of the report is covered by the current installer path; a stale host mount +is an environment cleanup item unless it reproduces on a clean `rc.3` install. + +### Are public issue comments or closures required for the RC? + +No public GitHub state changes are required just to prepare this packet. Draft +comments, closures, or retitles still need explicit maintainer approval before +posting. + +## Recommended Evaluation Path + +1. Back up the current system and keep direct console access available. +2. Confirm the current stable rollback command: + `./scripts/install.sh --version v5.1.29` +3. If the host was on `rc.2`, use a manual reinstall or explicit trust + migration path rather than assuming unattended auto-update continuity. +4. Upgrade the Pulse server in a staging or otherwise controlled environment. +5. Verify server health, version, logs, and update UI before upgrading agents. +6. Re-test Docker Unified Agent inside Proxmox LXC after restart and container + recreation. +7. Re-test alerts, backup/recovery, snapshots, PBS/ZFS attribution, Synology + RAID scrub handling, and Ceph inventory. +8. Re-test Workloads, Storage, and Infrastructure at desktop and mobile sizes. +9. Upgrade agents separately only when the user is explicitly testing the + v5-to-v6 agent path. + +## Ask For These Details + +When a user reports an `rc.3` problem, ask for: + +- current version and prior version +- install type +- whether the host was previously on v5, `rc.1`, or `rc.2` +- whether a manual reinstall or trust migration was used after `rc.2` +- whether the issue happened during server upgrade, agent upgrade, alerting, + backup/recovery, platform inventory, or first use +- whether Unified Agents were upgraded yet +- expected result +- actual result +- sanitized logs, screenshots, and diagnostics + +## Escalate Immediately + +Escalate without asking the user to keep experimenting when the report involves: + +- failed install or failed upgrade with no recovery path +- stable install path unexpectedly landing on a v6 prerelease +- duplicate or missing agent identity after a v5-to-v6 upgrade +- Docker LXC agent reconnect-token or identity loss after recreation +- monitoring or reporting that stops entirely after upgrade +- alert storms after notifications were explicitly disabled +- rollback failure or inability to return to v5.1.29 +- data-loss, destructive behavior, or security-sensitive regressions + +## Canonical References + +- `docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md` +- `docs/releases/V6_CHANGELOG_RC3_DRAFT.md` +- `docs/UPGRADE_v6.md` +- `docs/AGENT_SECURITY.md` +- `docs/MIGRATION_UNIFIED_NAV.md` diff --git a/scripts/release_control/documentation_currentness_test.py b/scripts/release_control/documentation_currentness_test.py index b3ddc98139..938ba62dd9 100644 --- a/scripts/release_control/documentation_currentness_test.py +++ b/scripts/release_control/documentation_currentness_test.py @@ -146,11 +146,14 @@ class DocumentationCurrentnessTest(unittest.TestCase): "docs/architecture/v6-pricing-and-tiering.md", "docs/releases/RELEASE_NOTES_v6.md", "docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md", + "docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md", "docs/releases/V6_CHANGELOG.md", "docs/releases/V6_CHANGELOG_RC1.md", "docs/releases/V6_CHANGELOG_RC2_DRAFT.md", + "docs/releases/V6_CHANGELOG_RC3_DRAFT.md", "docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md", "docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", + "docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", "frontend-modern/public/docs/README.md", ) forbidden_phrases = ( diff --git a/scripts/release_control/release_promotion_policy_test.py b/scripts/release_control/release_promotion_policy_test.py index 270d137362..2885708ae0 100644 --- a/scripts/release_control/release_promotion_policy_test.py +++ b/scripts/release_control/release_promotion_policy_test.py @@ -133,11 +133,15 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn("docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md", release_index) self.assertIn("docs/releases/V6_CHANGELOG_RC2_DRAFT.md", release_index) self.assertIn("docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", release_index) + self.assertIn("docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md", release_index) + self.assertIn("docs/releases/V6_CHANGELOG_RC3_DRAFT.md", release_index) + self.assertIn("docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", release_index) def test_operator_support_packs_keep_free_first_paid_continuity_wording(self) -> None: for rel in ( "docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md", "docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", + "docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", ): with self.subTest(rel=rel): support_pack = read(rel) @@ -202,11 +206,23 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn(f"`v{current_version}`", release_notes) self.assertIn(f"Pulse v{current_version}", changelog) else: - self.assertEqual(current_version, "6.0.0-rc.2") + packets = { + "6.0.0-rc.2": ( + "docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md", + "docs/releases/V6_CHANGELOG_RC2_DRAFT.md", + "docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", + ), + "6.0.0-rc.3": ( + "docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md", + "docs/releases/V6_CHANGELOG_RC3_DRAFT.md", + "docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", + ), + } + self.assertIn(current_version, packets) - release_notes = read("docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md") - changelog = read("docs/releases/V6_CHANGELOG_RC2_DRAFT.md") - operator_pack = read("docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md") + release_notes = read(packets[current_version][0]) + changelog = read(packets[current_version][1]) + operator_pack = read(packets[current_version][2]) self.assertIn(f"Pulse v{current_version} Draft Release Notes", release_notes) self.assertIn(f"`v{current_version}`", release_notes) @@ -238,7 +254,9 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn("docs/releases/V6_CHANGELOG.md", upgrade_guide) self.assertNotIn("docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", upgrade_guide) else: - self.assertIn("docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", upgrade_guide) + self.assertEqual(current_version, "6.0.0-rc.3") + self.assertIn("docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", upgrade_guide) + self.assertNotIn("docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", upgrade_guide) self.assertNotIn("docs/releases/V6_RC_OPERATOR_SUPPORT_PACK.md", upgrade_guide) def test_prerelease_feedback_template_uses_generic_current_rc_wording(self) -> None: @@ -467,7 +485,7 @@ class ReleasePromotionPolicyTest(unittest.TestCase): self.assertIn("operators know the update signer changed", normalize_ws(runbook)) self.assertIn("manual reinstall or other explicit trust-migration path", normalize_ws(runbook)) self.assertIn("points at the current in-repo draft packet", runbook) - self.assertIn('export RC_VERSION="6.0.0-rc.2"', runbook) + self.assertIn('export RC_VERSION="6.0.0-rc.3"', runbook) self.assertIn("printf '%s\\n' \"$RC_VERSION\" > VERSION", runbook) self.assertIn("markdown text from the current release-notes packet", runbook) self.assertIn("Keep the current release-notes, changelog, and operator-support packet in", runbook) diff --git a/scripts/release_control/render_release_body_test.py b/scripts/release_control/render_release_body_test.py index d1d62a8644..17a731934e 100644 --- a/scripts/release_control/render_release_body_test.py +++ b/scripts/release_control/render_release_body_test.py @@ -96,6 +96,9 @@ Old metadata section. "docs/releases/RELEASE_NOTES_v6_RC2_DRAFT.md", "docs/releases/V6_CHANGELOG_RC2_DRAFT.md", "docs/releases/V6_RC2_OPERATOR_SUPPORT_PACK_DRAFT.md", + "docs/releases/RELEASE_NOTES_v6_RC3_DRAFT.md", + "docs/releases/V6_CHANGELOG_RC3_DRAFT.md", + "docs/releases/V6_RC3_OPERATOR_SUPPORT_PACK_DRAFT.md", ) for relative_path in packet_paths: