Skip to content

Release note template

The canonical shape for a single release's notes. The release automation renders this into docs/releases/vX.Y.Z.md, substituting the version, date, and change lists. Keep it user-facing and terse; omit any heading with no entries.

Format

---
title: vX.Y.Z
---

# vX.Y.Z — YYYY-MM-DD

_One-sentence summary of the release._

## Added
- New capability, route, agent tool, or doc. (#PR / ISSUE)

## Changed
- Behavior change users will notice. (#PR / ISSUE)

## Fixed
- Bug fix. (#PR / ISSUE)

## Deprecated
- Something still working but slated for removal, with the migration path.

## Removed
- Something taken out (and what replaces it).

## Security
- Security-relevant fix or hardening.

## Upgrade notes
- Manual steps an operator must run (migrations, config changes, cleanup scripts). Omit if none.

Field notes

  • Heading # vX.Y.Z — YYYY-MM-DD — the version and the release date (ISO 8601). The title: front-matter (vX.Y.Z) is what shows in the site nav.
  • Change headings follow Keep a Changelog: Added, Changed, Fixed, Deprecated, Removed, Security. Only include the ones that apply.
  • References — link PRs/issues (#123) or Linear IDs where useful, so a reader can dig in.
  • Upgrade notes — call out anything an operator must do by hand: an Alembic migration (alembic upgrade head), a new required env var, or a maintenance script (e.g. sentinel-cleanup). Leave it out when the upgrade is drop-in.