# 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.

- Skill: `srombauts/sqlitecpp-release` (Agent Skill)
- Install (CLI): `npx skillmds@latest add srombauts/sqlitecpp-release`
- Raw SKILL.md: https://api.skillmd.com/api/skills/srombauts/sqlitecpp-release/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: srombauts (https://skillmd.com/u/srombauts)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/srombauts/sqlitecpp-release

---


# 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.