How do I bump the project version?

Table of Contents

The version bump is housekeeping that always accompanies Open a new sprint. Land it as a separate commit on the same sprint-open PR.

Question

How do I bump ORE Studio's project version across every file that mentions it?

Answer

Six files carry the version string or the last-released screenshot. Edit them as a single commit.

  1. Pick the new version. The project follows 0.0.<N> where N tracks the sprint number; bump N by one.
  2. Top-level CMakeLists.txt:

    -project(OreStudio VERSION 0.0.<OLD> LANGUAGES CXX
    +project(OreStudio VERSION 0.0.<NEW> LANGUAGES CXX
    
  3. vcpkg.json:

    -    "version-string": "0.0.<OLD>",
    +    "version-string": "0.0.<NEW>",
    
  4. The three GitHub workflow package filenames under .github/workflows/:

    • continuous-linux.ymlorestudio_0.0.<OLD>_amd64.deb
    • continuous-macos.ymlOreStudio-0.0.<OLD>-Darwin.dmg
    • continuous-windows.ymlOreStudio-0.0.<OLD>-win64.*

    Each is a single sed-able substitution.

  5. readme.org — four things:

    a. The sprint badge (line 25): update both the Sprint-<N> label and the href link sprint_<N>/sprint.html to the new sprint number:

    -<a href="...sprint_<OLD>/sprint.html"><img ... src=".../Sprint-<OLD>-blue.svg"/></a>
    +<a href="...sprint_<NEW>/sprint.html"><img ... src=".../Sprint-<NEW>-blue.svg"/></a>
    

    b. The "PRs since" static badge (line 43): update the label and the href's merged date filter to the new sprint start date. Use a static badge (img.shields.io/badge/PRs%20since%20v0.0.<NEW>-GitHub%20search-blue); do not use badge/dynamic/json with a GitHub Search API URL — shields.io rejects the url parameter when the inner URL contains query-string syntax:

    -<a href="...merged%3A%3E%3D<OLD-DATE>"><img alt="PRs since v0.0.<OLD>" src="...badge/PRs%20since%20v0.0.<OLD>-GitHub%20search-blue"/></a>
    +<a href="...merged%3A%3E%3D<NEW-DATE>"><img alt="PRs since v0.0.<NEW>" src="...badge/PRs%20since%20v0.0.<NEW>-GitHub%20search-blue"/></a>
    

    c. The "commits-since" badge, which uses the previous version tag — so when bumping from 0.0.<OLD> to 0.0.<NEW>, the commits-since badge moves from v0.0.<OLD-1> to v0.0.<OLD>.

    d. The screenshot asset reference: the readme shows the last released version, so point it at the just-closed sprint's screenshot — assets/images/ore_studio-v0.0.<OLD>.png, captured at that sprint's close (see How do I generate release notes? step 6). It should already exist by the time you're opening the next sprint; if it doesn't, capture it now rather than leaving the reference stale:

    -[[./assets/images/ore_studio-v0.0.<OLD-1>.png]]
    +[[./assets/images/ore_studio-v0.0.<OLD>.png]]
    
  6. index.org (the site homepage) has its own copy of the same screenshot, near the top — update it identically and don't forget it, it's easy to miss since it's a separate file from readme.org:

    -[[./assets/images/ore_studio-v0.0.<OLD-1>.png]]
    +[[./assets/images/ore_studio-v0.0.<OLD>.png]]
    
  7. Verify. Sanity-check that nothing else mentions the old version:

    grep -rn "0\.0\.<OLD>" \
        CMakeLists.txt vcpkg.json .github/workflows readme.org index.org
    

    Expect zero matches.

  8. Commit as [build] Bump version to 0.0.<NEW> on the sprint-open branch. No separate PR needed.

Script

No wrapper — the five files are touched manually because every release confirms the diffs by eye.

Tested by

CI builds the renamed package artefacts. If the workflow paths and the actual package name disagree, the artefact upload step fails on the post-build run.

See also

Emacs 29.3 (Org mode 9.6.15)