Versioning Policy

Semantic Versioning

MAJOR.MINOR.PATCH[-prerelease]

1.0.0  → Initial production launch (MVP)
1.1.0  → New feature (podcast page redesign)
1.1.1  → Bug fix (form validation)
2.0.0  → Breaking change (full rebrand or stack change)

Change Type	Bump	Example
Breaking change, full rebrand, stack migration	MAJOR	1.x.x → 2.0.0
New page, new section, new integration	MINOR	1.0.x → 1.1.0
Bug fix, copy correction, style fix	PATCH	1.0.0 → 1.0.1

Automated via semantic-release

Versions are never set manually. semantic-release runs on every merge to main and:

1. Analyzes commit messages
2. Determines the next version number
3. Updates package.json
4. Generates/updates CHANGELOG.md
5. Creates a GitHub Release + tag

Commit → Version Mapping

Commit type	Release
feat:	MINOR
fix:, perf:	PATCH
BREAKING CHANGE: (in footer)	MAJOR
chore:, docs:, style:, test:, ci:	No release

Version Lifecycle

v0.x.x-dev    ← Active development (current)
v1.0.0-mvp    ← MVP feature-complete, ready for first production deploy
v1.0.0        ← Production launch
v1.1.0        ← First post-launch feature iteration

Current Version

cat package.json | grep '"version"'

Full release history: CHANGELOG.md