메뉴
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.