# Version Increment

> Prepare the repository for a new release tag by updating hard-coded version references, promoting CHANGELOG Unreleased entries, and running release-readiness checks.

- Skill: `nasa/version-increment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nasa/version-increment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nasa/version-increment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nasa (https://skillmd.com/u/nasa)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nasa/version-increment

---


# Version Increment

Use this skill when the user provides a new version number and wants the repo prepared for tagging.

## Inputs

- `new_version` (required), semver-like string (example: `3.0.4`).
- `release_date` (optional). If omitted, use local current date (`YYYY-MM-DD`).

## Known Hard-Coded Version Locations (current repo)

- `CMakeLists.txt` (`project(... VERSION x.y.z)`).
- `source/bind/python/cea/__init__.py` (`__version__ = "x.y.z"`).
- `docs/source/conf.py` (`release = '...'`).
- `project.md` (`version: x.y.z`) — FORD doc-generator metadata; currently unreferenced elsewhere in the repo/CI, kept accurate in case FORD is reintroduced.
- `Doxyfile` (`PROJECT_NUMBER = x.y.z`) — Doxygen config invoked by docs.yml; feeds the Doxygen->Breathe->Sphinx pipeline but the value itself doesn't appear to render on the published site.

Update these locations and verify no additional hard-coded version literals remain outside generated docs.

## Workflow

1. Validate `new_version` format and ensure it is greater than the current version.
2. Update the five known hard-coded version locations.
3. Search for additional stale literals:
   - Prefer `rg -n "<old_version>|release\s*=|__version__\s*=|VERSION\s+[0-9]+\.[0-9]+\.[0-9]+"`
   - Exclude generated docs: `docs/_build/`, `docs/doxygen/`.
4. Update `CHANGELOG.md`:
   - Move current `## [Unreleased]` entries into a new release section `## [<new_version>] - <release_date>`.
   - Recreate an empty `## [Unreleased]` section at the top with standard subsections used by this repo.
5. Run sanity checks:
   - Ensure changed files are limited to release metadata/docs unless user asked for more.
   - Optionally run targeted tests/docs build if requested.
6. Report exact files changed and any warnings before tagging.

## Output Format

- New version and date used.
- List of updated files with one-line reason each.
- Warnings/blockers before tag creation.
- Suggested tag command: `git tag v<new_version>` (only if user asks to tag).

## Guardrails

- Do not create/push tags unless explicitly requested.
- Do not edit generated docs under `docs/_build/` or `docs/doxygen/`.
- Keep changelog wording user-visible and avoid implementation-only noise.