Releases

How website releases, changelogs, package versions, and release-please fit together.

The website repository uses release-please through GitHub Actions. Releases are driven by commit history and release-please metadata, not by hand-editing package versions.

flowchart LR
A[Conventional
commits]
B[GitHub
Actions]
C[release-please]
D[Release PR]
E[CHANGELOG.md]
F[package
versions]
G[release
manifest]
H[GitHub
release]

A --> B
B --> C
C --> D
D --> E
D --> F
D --> G
D --> H

Before merging a release-facing website change:

Run npm run build.
Run npm run lint or the relevant narrower check.
Confirm .release-please-manifest.json still matches the intended current release.
Avoid manual edits to generated release notes unless you are correcting release metadata.

Changelog handling

CHANGELOG.md stays at the repository root because release-please expects it there. The public docs should explain release process and link to GitHub releases when needed; they should not duplicate the generated changelog body.

What release-please owns

File	Ownership
`CHANGELOG.md`	Release history generated by release-please
`package.json`	Package version updated by release-please
`package-lock.json`	Lockfile package version updated with `package.json`
`.release-please-manifest.json`	Current release baseline read by release-please
`release-please-config.json`	Release type, changelog sections, and bump map

Do not hand-bump the website package version

When the website version drifts from .release-please-manifest.json, release-please can propose the wrong next version. Let release-please update package versions unless you are deliberately repairing release metadata.

Commit messages

Use conventional commits. For the contributor workflow around local checks and commits, see Commit style.

docs: update access-control setup flow
fix(layout): prevent docs callout overflow
style: normalize documentation spacing
ci: update release-please workflow

The repository maps common non-feature types such as docs, style, refactor, test, build, ci, and chore to patch releases.

Repair version synchronization

Only do this when release metadata is already wrong.

Identify the current active tag:
```
git describe --tags --abbrev=0
```
Confirm .release-please-manifest.json matches the current baseline:
```
{
  ".": "2.16.0"
}
```
Keep package.json and the top-level package entry in package-lock.json aligned to the same website release version.
Run npm run build.
Commit the repair with a clear message such as:
```
chore: sync release metadata
```