gsadmin/pulse
1
0
Fork 0
mirror of https://github.com/rcourtman/Pulse.git synced 2026-09-10 02:25:56 +00:00
Code Issues Packages Projects Releases Wiki Activity

Refresh v6 GA publication metadata

Browse Source
This commit is contained in:
rcourtman
2026-07-04 10:30:10 +01:00
parent d156ef7469
commit 63bbbb1508
9 changed files with 201 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/UPGRADE_v6.md
+7 -4
View File
@@ -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
docs/release-control/v6/internal/V5_MAINTENANCE_SUPPORT_POLICY.md
+2 -2
View File
@@ -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.
docs/release-control/v6/internal/records/current-branch-ga-owner-approval-2026-07-02.md
+3 -3
View File
@@ -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
docs/release-control/v6/internal/records/known-rc-issue-closure-for-ga-2026-07-04.md
+155
View File
@@ -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.
docs/release-control/v6/internal/records/rc-to-ga-promotion-readiness-blocked-2026-04-04.md
+15 -12
View File
@@ -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
docs/release-control/v6/internal/subsystems/deployment-installability.md
+3 -3
View File
@@ -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
docs/releases/RELEASE_NOTES_v6.md
+8 -5
View File
@@ -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
scripts/release_control/release_promotion_policy_test.py
+4 -4
View File
@@ -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")
scripts/release_control/resolve_release_promotion_test.py
+4 -4
View File
@@ -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"):