| name | sqlitecpp-release |
| description | SQLiteCpp release procedure: bump the version across all files, finalize the CHANGELOG, open the Release PR, and tag. Use when cutting a new release, bumping the project version, or tagging. |
SQLiteCpp Release
How to cut a new SQLiteCpp release once the changes for it have landed on master. The per-PR
CHANGELOG and branching rules live in [[sqlitecpp-workflow]] and [[sqlitecpp-git-branching]].
1. Start a release branch
Branch from an up-to-date master: release-X.Y.Z (see [[sqlitecpp-git-branching]]).
2. Finalize the CHANGELOG
The entries should already be there from each PR (see [[sqlitecpp-workflow]]). For the release:
- Rename the heading from
Version X.Y.Z - <year> ??? to the real release date,
e.g. Version 3.4.0 - 2026 Jun 22.
- Confirm every merged PR since the previous tag has a bullet, including any change committed
directly to master.
3. Bump the version
Keep all of these in sync. The four-place version (e.g. 3.4.0) and the zero-padded macro form
(e.g. "3.04.00" / 3004000) must match.
CMakeLists.txt: project(SQLiteCpp VERSION X.Y.Z)Doxyfile: PROJECT_NUMBER = X.Y.Zpackage.xml: <version>X.Y.Z</version>meson.build: version: 'X.Y.Z',include/SQLiteCpp/SQLiteCpp.h:
#define SQLITECPP_VERSION "X.0Y.0Z" (each component zero-padded to two digits)#define SQLITECPP_VERSION_NUMBER XYYZZ (e.g. 3.4.0 -> 3004000)
The header carries a WARNING: shall always be updated in sync with PROJECT_VERSION comment. Honor
it: a mismatch between the header macros and CMakeLists.txt is the most common release mistake.
Commit as Update project version to X.Y.Z.
4. Open the Release PR
Open a PR titled Release X.Y.Z. GitHub's "Generate release notes" lists the merged PRs and new
contributors; that summary is for the GitHub Release body, while CHANGELOG.md stays the
hand-curated record.
5. Tag after merge
After the Release PR merges, create the lightweight tag X.Y.Z (no v prefix, matching existing
tags) on the merge commit and publish the GitHub Release with the generated notes.
Version numbering
- Patch (
Z) for fixes and build tweaks only.
- Minor (
Y) when adding features, public API, or CMake/Meson options, or for a non-trivial SQLite
bump.
- Major (
X) for breaking API changes or a raised C++/CMake baseline.
