| name | version-bump |
| description | Bump the libnpy library version for release. Use when: updating the version number, preparing a release, changing the version to a specific value, writing a CHANGELOG entry from recent commits. |
| argument-hint | Target version, e.g. 2.2.0 |
Version Bump
Bump the libnpy version across all files and generate a CHANGELOG entry from recent commits.
When to Use
- The maintainer asks to bump / change / update the version (e.g. "Bump the version to 2.2.0")
- Preparing a new release of the library
Procedure
1. Parse the requested version
Extract the target version string (MAJOR.MINOR.PATCH) from the user's request.
Read the current version from the VERSION file in the repository root.
Abort if the requested version equals the current version.
2. Update every version location
Apply the new version to all of the following files. No other files contain the version.
| File | What to change |
|---|
VERSION | Replace the entire file content with the new version string (no trailing newline beyond what exists). |
vcpkg.json (repo root) | Update the "version" field value. |
ports/matajoh-libnpy/vcpkg.json | Update the "version" field value. |
test/vcpkg/port/matajoh-libnpy/vcpkg.json | Update the "version" field value. |
include/npy/npy.h | Update all four preprocessor defines: NPY_VERSION_MAJOR, NPY_VERSION_MINOR, NPY_VERSION_PATCH, and NPY_VERSION_STRING. |
Do not touch CMakeLists.txt — it reads the version dynamically from the VERSION file.
3. Generate the CHANGELOG entry
Run git log to collect commits on the current branch since the latest release tag.
Use a command like:
git log --oneline --no-decorate $(git describe --tags --abbrev=0)..HEAD
If no tags exist, fall back to:
git log --oneline --no-decorate -20
Compose a new entry and prepend it to CHANGELOG.md immediately after the # Changelog heading, using this exact format:
## [YYYY-MM-DD - Version X.Y.Z](https://github.com/matajoh/libnpy/releases/tag/vX.Y.Z)
One-sentence summary of the release theme.
Improvements:
- Item 1
- Item 2
Bugfixes:
- Item 1
Rules for the entry:
- Use today's date in
YYYY-MM-DD format.
- Categorise changes under Improvements and/or Bugfixes (omit a category if empty).
- Write entries in simple past tense, concise, one line each.
- Do not include merge commits, version-bump commits, or trivial CI-only changes unless they are user-facing.
- Match the tone and style of the existing entries in
CHANGELOG.md.
4. Update RELEASE_NOTES
Replace the entire content of the RELEASE_NOTES file with the body of the new changelog entry (everything after the ## [...] heading line). This file is plain text with no markdown heading.
5. Verify
After all edits, run a search for the old version string across the repository to confirm no stale references remain. Report the result to the maintainer.
6. Present changes for review
List every file modified and summarise the changes so the maintainer can review before committing.
