# Release policy

## Release metadata

`VERSION` is the runtime source of truth. Each published release must have:

- The same version in `VERSION`, the newest numbered `CHANGELOG.md` section and
  the Git tag (`vX.Y.Z`).
- A changelog date matching its actual publication calendar date in Europe/Vienna.
- A tag pointing to the tested commit merged into `main`.
- Upgrade notes for API, runtime, storage or authentication changes.

The `Unreleased` section holds work awaiting the next release. A merge alone does
not publish a release. Under Semantic Versioning, incompatible documented API
changes require a major version, compatible features a minor version, and
compatible fixes a patch version. Do not rename or move existing published tags.

## Release checklist

1. Review changes since the previous release and determine the version from the
   documented compatibility impact.
2. Update `VERSION`, move pending changelog entries into a dated version section,
   leave a fresh `Unreleased` section and document upgrade steps.
3. Submit a release pull request and merge it through the protected `main` branch.
4. Verify the merge commit's CI and the version rendered by `raijuVersion()`.
   Check that the release archive includes `VERSION` and the complete core.
   For routing, login-destination or handler-directory changes, also record the
   [Apache routing verification](ROUTING.md#required-verification) for that code.
5. Create an annotated `vX.Y.Z` tag on that exact merge commit.
6. Read back the tag target and the archive version.

## Release history

| Version | Date | Notes |
| --- | --- | --- |
| 1.0.0 | 2026-10-25 | Initial release, based on baseline commit `98067c90`. |