Release notes¶
Every tagged Polaris release gets a dated notes page under docs/releases/. This index is the
canonical list; each entry links to the full notes for that version. New releases are added at the
top of the table.
Automated
Release notes are written by the polaris-release skill / release.sh, not by hand. See
Cutting a release below for the flow, the file/version conventions, and the
page format (template).
Releases¶
| Version | Date | Highlights | Notes |
|---|---|---|---|
v0.7.0 |
2026-08-23 | The question loop and its CLI, authenticated operator MCP sessions, corpus quality behind an autonomy rubric | notes |
v0.6.1 |
2026-07-29 | Feature flags, tenant account management, capability dashboard, password toggle, graphify tooling | notes |
v0.6.0 |
2026-07-27 | Brain/version discovery via GET /v1/me + Settings Brain Info; resizable & collapsible agent chat drawers; adaptive Settings layout; procedural per-agent page headers |
notes |
v0.5.1 |
2026-07-27 | Self-service brain discovery for API keys (GET /v1/me) + a zero-dependency Completions verification client; OpenAI API docs updated |
notes |
v0.5.0 |
2026-07-27 | Hosted workspace docs + clickable citation/wiki deeplinks; live extraction progress + restart; wiki stewardship & share links; Neo4j retired | notes |
v0.4.0 |
2026-07-22 | Sentinel goes live; Scout + Sentinel conversational; release versioning | notes |
v0.3.11 |
2026-07-22 | Version-tracking baseline — four agents, gateway + SPA, governed knowledge pipeline | notes |
Unreleased¶
Changes merged since the last tag accumulate here. When a version is cut, the release hook moves this
section into a new vX.Y.Z.md page, stamps it with the date, links it from the table above, and
clears this list.
- (nothing yet)
Versioning¶
Polaris uses Semantic Versioning: MAJOR.MINOR.PATCH.
- MAJOR — incompatible API/contract changes (gateway
/v1, MCP surface, on-disk formats). - MINOR — backwards-compatible functionality (a new agent capability, a new route, a new tool).
- PATCH — backwards-compatible fixes.
The source of truth for the current version is the top-level VERSION file (a single line, e.g.
0.3.11). release.sh mirrors it into pyproject.toml (and web/brain-builder/package.json if the
frontend is versioned in lockstep). Git tags are vX.Y.Z. The increment levels map to SemVer as:
build → patch (0.3.11 → 0.3.12), minor → (0.3.11 → 0.4.0), major →
(0.3.11 → 1.0.0).
Cutting a release¶
Releases are skill-driven: you merge locally, then Claude authors the notes.
- Merge your feature branch into
devlocally (git checkout dev && git merge <feature>), or let the skill do it. - In Claude Code, invoke the
polaris-releaseskill (.claude/skills/polaris-release/):call the polaris-release skill to increment the build version, generate the release notes, and push dev (from:
<feature-branch>)
The skill reads the branch diff, runs release.sh to bump the version + scaffold the notes page,
writes end-user-facing notes into it, then commits, tags vX.Y.Z, and pushes dev.
A committed .githooks/post-merge reminder nudges you toward the skill whenever a feature branch
merges into dev. Enable the committed hooks once per clone:
What release.sh does (the deterministic core)¶
./scripts/release.sh --increment build|minor|major [--from <branch>] [--to dev]:
- Bumps the
VERSIONfile and mirrors it intopyproject.toml. - Scaffolds
docs/releases/vX.Y.Z.mdfrom the template shape (named exactlyvX.Y.Z.md, lowercasev), embedding the--from..--tocommit list as material. - Inserts a Releases table row above (version · date ·
_summary_placeholder · notes link). - Adds a
mkdocs.ymlnav entry beneathTemplate.
It does not run git — no merge, commit, tag, or push. The skill (or you) fills the notes content,
replaces the _summary_ cell with a one-line highlight, and handles git.
Keep entries terse and user-facing — what changed and why it matters, not commit-by-commit detail. Group changes under the standard headings (Added / Changed / Fixed / Deprecated / Removed / Security); omit empty ones. See the template for the exact shape.