Releasing

Releasing

Versions follow Semantic Versioning, with tags named vMAJOR.MINOR.PATCH. The CMake package declares SameMajorVersion compatibility, so a minor release must not break the API.

Choose the version

python3 scripts/ci/semver_check.py

It reads the commits since the last tag: feat means minor, fix means patch, and ! or BREAKING CHANGE: means major. Check its answer against the actual changes. For 1.1.0 it suggested 1.0.1, because a backward-compatible API addition (enable_module() returning bool) had been committed as a fix.

Steps

1. On a chore/release-X.Y.Z branch:

   • bump project(coretrace-logger VERSION X.Y.Z) in CMakeLists.txt;
   • set GIT_TAG vX.Y.Z in the README's FetchContent example;
   • in CHANGELOG.md, rename ## Unreleased to ## vX.Y.Z and end the section with [Full vX.Y.Z notes](https://github.com/CoreTrace/coretrace-log/releases/tag/vX.Y.Z).;
   • update the README and this wiki for the behavior that changed.

2. Open a pull request chore(release): prepare vX.Y.Z that contains the draft release notes. Merge it once CI is green.

3. Tag the merge commit and publish the release:

   gh release create vX.Y.Z --target <merge-commit> --title vX.Y.Z --notes-file notes.md

   --target takes the full SHA of the merge commit (git rev-parse HEAD on an up-to-date main) or a branch name. GitHub rejects a short SHA with HTTP 422: target_commitish is invalid.

4. Check that find_package(coretrace-logger X.Y) finds the installed package.

Past releases and their notes are on the releases page.