build: single-source the version in a VERSION file - #25
Merged
Merged
Conversation
The version was duplicated across CMakeLists.txt (project(VERSION ...)), package.nix (the Nix flake added recently), and debian/changelog, with nothing keeping them in sync, so a release bump could easily ship a mislabeled artifact. Introduce a top-level VERSION file as the single source of truth: - CMakeLists.txt reads it via file(STRINGS) and passes it to project(), so MITHRIL_VERSION still flows from PROJECT_VERSION. - package.nix reads the same file via lib.fileContents. debian/changelog cannot derive its value (dpkg needs a literal and it carries its own -N Debian revision plus changelog history), so the release workflow gains a Version consistency step that fails the build if the git tag or debian/changelog upstream version disagrees with VERSION. CMake and Nix derive from VERSION and cannot drift. Cutting a release is now: edit VERSION, add a debian/changelog stanza, tag v<VERSION>. Verified the version flows end to end (binary reports VERSION) and the full suite stays green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Make a top-level
VERSIONfile the single source of truth for the version.Why
The version was duplicated across
CMakeLists.txt(project(VERSION ...)),package.nix(the Nix flake), anddebian/changelog, with nothing keepingthem in sync. A release bump could update one and miss another, shipping a
mislabeled artifact.
What
VERSION(new, repo root) holds the number once (0.2.1).CMakeLists.txtreads it withfile(STRINGS)and passes it toproject(), soMITHRIL_VERSIONstill flows fromPROJECT_VERSION.package.nixreads the same file withlib.fileContents..github/workflows/release.ymlgains a Version consistency step. CMakeand Nix derive from
VERSIONand cannot drift;debian/changelogand thegit tag carry the number independently, so the release fails if either
disagrees with
VERSIONrather than publishing a mislabeled build.debian/changelogis intentionally not derived: dpkg needs a literal, and thefile carries its own
-NDebian revision plus changelog history. The CI guardkeeps it honest instead.
Release flow after this
Edit
VERSION, add adebian/changelogstanza, tagv<VERSION>.Testing
VERSIONto adifferent value makes
mithril --versionreport it; restored to0.2.1.debian/changelogand matchesVERSION.