Run any Skill in Manus with one click

sqlitecpp-release

Stars2,751

Forks569

UpdatedJune 22, 2026 at 20:20

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

SRombauts

SRombauts/SQLiteCpp

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

SKILL.md

readonly

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.

More from this repository

same repository

sqlitecpp-ci-workflows

SRombauts/SQLiteCpp

SQLiteCpp CI workflow patterns. Use for GitHub Actions, AppVeyor, Travis, matrices, or test steps.

2026-06-282.8k

windows-shell-commands

SRombauts/SQLiteCpp

Running shell commands on this Windows checkout via the PowerShell and Bash tools, and passing multi-line or quoted arguments (commit messages, PR bodies, file content) without corruption. Use when running git or gh with multi-line or quoted input, writing a commit message or PR body from the command line, reaching for a heredoc or here-string, or after a message or body comes out wrapped in stray characters such as a leading and trailing `@`.

2026-06-282.8k

sqlitecpp-workflow

SRombauts/SQLiteCpp

SQLiteCpp change workflow checklists for API, tests, build files, and CHANGELOG updates. Use when adding a method or class, editing build files, or writing a CHANGELOG entry for a PR.

2026-06-272.8k

sqlitecpp-coding-standards

SRombauts/SQLiteCpp

SQLiteCpp coding standards and API rules for core edits, public headers, style, and Doxygen.

2026-06-262.8k

agent-response-style

SRombauts/SQLiteCpp

Default response behavior for AI coding agents: professional, factual, neutral tone with calibrated critical evaluation. Baseline for every task: implementation, code review, debugging, planning, research, evaluation, Q&A.

2026-06-222.8k

skill-maintenance

SRombauts/SQLiteCpp

Editing conventions for files under `.claude/skills/**` (markdown style, frontmatter format, SKILL.md vs `references/` split, upstream-vendored skills). Use when creating a new skill, editing any `SKILL.md` or `references/*.md` file, refactoring a skill description, or after adding/removing a skill.

2026-06-222.8k

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

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.