sqlitecpp-workflow

name	sqlitecpp-workflow
description	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 Workflow

Change checklist

• Public API has Doxygen (@brief, @param, @return, @throw).
• Tests added under tests/.
• Build files updated (CMakeLists.txt, meson.build).
• CHANGELOG.md updated for user-facing changes (in a separate commit after opening the PR).

CHANGELOG conventions

Update CHANGELOG.md in the same PR that makes the change, but in a separate commit created after the PR is opened so the PR number is known. Add one line per PR under the current unreleased version heading (Version X.Y.Z - <year> ???). Create that heading if it does not exist yet.

• One bullet per PR: - <description> (#NNN). The PR number is the last token, in parentheses.
• Write in the imperative mood, present tense: "Add", "Fix", "Update", "Remove". Not "Added", "Fixes", or "Adding".
• Keep each entry to a single line that names the user-facing effect, not the internal mechanics.
• Put the SQLite version bump first when the release includes one (see [[sqlitecpp-update-sqlite]]).
• Order the rest roughly as features, fixes, build/CI, then docs and tooling.
• A change merged straight to master without a PR still gets a bullet; omit the and note it was committed directly to master.