Skip to content

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.110.3.12), minor → (0.3.110.4.0), major → (0.3.111.0.0).

Cutting a release

Releases are skill-driven: you merge locally, then Claude authors the notes.

  1. Merge your feature branch into dev locally (git checkout dev && git merge <feature>), or let the skill do it.
  2. In Claude Code, invoke the polaris-release skill (.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:

git config core.hooksPath .githooks

What release.sh does (the deterministic core)

./scripts/release.sh --increment build|minor|major [--from <branch>] [--to dev]:

  1. Bumps the VERSION file and mirrors it into pyproject.toml.
  2. Scaffolds docs/releases/vX.Y.Z.md from the template shape (named exactly vX.Y.Z.md, lowercase v), embedding the --from..--to commit list as material.
  3. Inserts a Releases table row above (version · date · _summary_ placeholder · notes link).
  4. Adds a mkdocs.yml nav entry beneath Template.

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.