Releases and Versioning

The steps below mirror docs/deployment.md, "Releases", which is the source of truth.

HolidayOps uses semantic versioning: vMAJOR.MINOR.PATCH.

Version	Means
0.x	before the public launch; the API can still change between minor versions
1.0.0	the hosted launch; from then on, breaking API changes need a new major version and a new /api/v2/ path
minor (x.Y.0)	new features, no breaking changes
patch (x.y.Z)	fixes only

What a release is

• A git tag vX.Y.Z on main, with a GitHub release whose notes come from CHANGELOG.md.
• The production image for that commit, ghcr.io/ahmershahdev/holidayops:<commit sha>.
• The version in backend/pyproject.toml and frontend/package.json matches the tag.

The changelog is dated, not versioned, because the site renders it at /changelog/. A release covers every changelog entry since the previous tag.

Making a release

1. Bump the version in backend/pyproject.toml and frontend/package.json in a pull request.
2. Run the attack simulation against the production image (see Self Hosting).
3. After the merge, tag the merge commit and publish the release:

git checkout main && git pull
git tag -a v0.2.0 -m "v0.2.0"
git push origin v0.2.0
gh release create v0.2.0 --verify-tag --title "v0.2.0" --notes-file notes.md

Mark releases before 1.0.0 as pre-releases.