Release

Maintainers: follow this checklist before creating a new tag.

Pre-release checklist

Update version and docs
- Ensure CHANGELOG.md has an entry for the new version (e.g. [1.0.6] - YYYY-MM-DD) and that [Unreleased] is updated or empty.
- Ensure UPGRADING.md mentions any behaviour changes for that version if needed.
Run quality checks
```
make release-check
```
This runs: composer-sync, cs-fix, cs-check, rector-dry, phpstan, test-coverage, and demo verification.

Commit any changes (e.g. changelog, version bumps). Ensure the tree is clean and pushed:

git status
git add -A && git commit -m "Release v1.0.6"   # if needed
git push origin main

Create an annotated tag (replace with the version you are releasing, e.g. v1.0.6). Ensure you have at least one commit before tagging:
```
git tag -a v1.0.6 -m "Release v1.0.6"
git push origin v1.0.6
```
If the bundle is developed in a monorepo and released from a separate clone (e.g. nowo-tech/SerialNumberBundle), run these commands in the clone that is pushed to the release remote.
GitHub release
The release workflow runs on tag push and creates the GitHub Release (including “Latest”) with body from the tag message and CHANGELOG.md. No manual draft needed unless you want to edit the notes.
Packagist
If the package is on Packagist, the new tag will be picked up automatically (or use “Update” there).