Skip to main content

sqlitecpp-release

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.

Source facts

Repository
SRombauts/SQLiteCpp
Last source activity
June 22, 2026 at 20:20
Detected SKILL.md language
English
Stars
2,789
Forks
575

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
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.Z` - `package.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.
View on GitHub