pulse-triage[bot]
022b55083d
Bind stable notes to version and operator disclosures rather than obsolete prose. Support bounded grouped customer sections for v6.4.6 and later, align generation and rendering, and preserve published history and all qualification gates. Change-source: pulse-maintainer
3.2 KiB
Pulse vX.Y.Z Release Notes
One short paragraph explaining the customer outcome of the release. Lead with what feels better or works now, not how it was implemented.
Highlights
- One to three short plain-text outcomes. Keep each under 140 characters with no Markdown, links or issue references so the in-app highlights stay readable.
Proxmox, PBS and backups
- Explain a change in plain language, where users notice it and why it matters.
From v6.4.6 onward, group related changes under the relevant reader-facing headings: Alerts and notifications, Disks and storage, Proxmox, PBS and backups, TrueNAS, vSphere and Docker, Install, updates and agents, Updates and agents, Pulse Pro, AI and hosted, Monitoring and service health, Security, and Other improvements. Omit unused groups. A narrow patch can keep the simpler section below instead. Do not repeat a change between groups or add empty sections.
What's improved
- Short outcome - Explain where users notice it and why it matters.
- Short outcome - Keep each item concrete and independently useful.
- Short outcome - Include fixes here as outcomes rather than repeating them in a second section.
Use a concise set of meaningful improvements. A narrow patch may use fewer rather than padding the notes with internal work. Each user-visible change belongs in the grouped changes exactly once. Prefer observable behavior over component names, group related implementation work into one user-recognizable theme, and use plain language. Each complete bullet, including Markdown links, must be no more than 260 characters. New release notes must not contain semicolons or em dashes.
For an RC, cover only changes since the immediately preceding RC (or the previous stable release for RC1). Do not repeat improvements already announced in an earlier RC. For a stable GA release, cover the complete release train since the previous stable release and boil the full commit range down to a few themes that explain what users will experience differently. Do not concatenate the RC notes or attempt to list every commit. The generator supplies the range, read-only repository and GitHub tools, an unbounded factual investigation, an independent draft that cannot see that investigation, and a final model that receives both. The models decide what to inspect, what matters, and how to tell the release story. The harness owns the release boundary, public format, safety constraints, and optional per-pass traces.
Do not add a separate Fixes section. That shape encourages the same change to
be described twice as both an improvement and a fix.
Known issues
Describe remaining user symptoms and an actionable workaround or next step. Omit this section when there are none. Do not substitute internal verification status for information users can act on.
Before you upgrade
Include only compatibility, migration, signing, companion-app, known-risk, or required operator information. Omit this section when users do not need to do or understand anything before upgrading.
The release pipeline appends the Install and Roll back sections from
governed version metadata. Do not add release qualification, validation,
workflow, gate, governance, or promotion-metadata sections to the customer
notes.