Releasing job-applicator

This document describes the project release process.

Versioning

This project follows Semantic Versioning:

The version is declared in two places that must stay in sync:

Ensure the main branch is green.

git checkout main
git pull origin main
ruff check src/ tests/
ruff format --check src/ tests/
mypy src/
pytest -m unit -x

Decide the new version based on the changes since the last release.
Run the release script.
```
bash scripts/release.sh <version>
```
This will:
- Validate the working tree and test suite
- Update pyproject.toml and src/job_applicator/__init__.py
- Insert a dated section into CHANGELOG.md from [Unreleased]
- Commit the version bump and changelog update
- Create an annotated Git tag (v<version>)
- Build the package distribution
- Optionally push the tag (disabled by default; enable with --push)
Publish the release.
- Push the release commit and tag:
```
git push origin main
git push origin v<version>
```
- Create a GitHub Release from the tag and paste the relevant CHANGELOG.md section into the release notes.
- Publish to PyPI (if/when configured):
```
python -m twine upload dist/*
```

For urgent fixes against the latest release:

Create a branch from the latest release tag:
```
git checkout -b hotfix/vX.Y.Z vX.Y.Z-1
```
Apply the fix, run tests, and bump the patch version with the release script.
Tag and publish as above, then cherry-pick or merge the fix back to main.

For alpha/beta/rc versions use the script with a pre-release suffix:

bash scripts/release.sh 0.4.0a1

Pre-release tags follow PEP 440 (e.g. 0.4.0a1, 0.4.0b2, 0.4.0rc1).