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.

Informações da origem

Repositório
SRombauts/SQLiteCpp
Última atividade na origem
22 de junho de 2026 às 20:20
Idioma detectado do SKILL.md
inglês
Estrelas
2.789
Forks
575

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

Exibindo SKILL.md

SKILL.md
Instruções da origem · Visualização somente leitura
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.
Ver no GitHub