菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
SQLiteCpp CI workflow patterns. Use for GitHub Actions, AppVeyor, Travis, matrices, or test steps.
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 `@`.
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.
SQLiteCpp coding standards and API rules for core edits, public headers, style, and Doxygen.
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.
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.
| 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. |
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]].
Branch from an up-to-date master: release-X.Y.Z (see [[sqlitecpp-git-branching]]).
The entries should already be there from each PR (see [[sqlitecpp-workflow]]). For the release:
Version X.Y.Z - <year> ??? to the real release date,
e.g. Version 3.4.0 - 2026 Jun 22.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.
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.
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.
Z) for fixes and build tweaks only.Y) when adding features, public API, or CMake/Meson options, or for a non-trivial SQLite
bump.X) for breaking API changes or a raised C++/CMake baseline.