Cmake improvements versioning release#200
Merged
caitlinross merged 6 commits intoMay 22, 2026
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #200 +/- ##
=======================================
Coverage 47.86% 47.86%
=======================================
Files 37 37
Lines 4745 4745
Branches 857 857
=======================================
Hits 2271 2271
Misses 2469 2469
Partials 5 5 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Bumps the top-level cmake_minimum_required from 3.5 to 3.16, needed for modern install/export machinery used in later phases of the CMake modernization plan. Replaces PROJECT(ROSS_TOP C) with a modern project(ross VERSION ... DESCRIPTION ... HOMEPAGE_URL ... LANGUAGES C) call. The version is parsed from git_describe_working_tree, which now runs at top level before project() rather than inside core/. Adds a regex-guarded fallback to 0.0.0 with a WARNING when git-describe cannot produce a numeric version (tarball / shallow clone / no-tag builds) — project(VERSION ...) errors on malformed input rather than no-op'ing the way the old string(REGEX REPLACE) calls did.
Improve the versioning process so that we have a .version file that will be updated at release time.
We will start following a more formal release process as well as providing a way for developers to add info on changes that should go in release notes, making it easier to write these notes for the future.
caitlinross
force-pushed
the
cmake-improvements-versioning-release
branch
from
5b3a2cd to
b120905
Compare
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
1 participant
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.
Starting improvements in CMake and formalizing a release-process infrastructure that the rest of the modernization will use.
CMake minimum bumped to 3.16
cmake_minimum_requiredmoves from 3.5 (2016) to 3.16 (late 2019). 3.5 predates a lot of the modern target/install/export machinery the rest of the modernization plan uses. 3.16 ships with Ubuntu 20.04, RHEL 9, and is a reasonable floor for current HPC environments.Versioning sourced from a tracked
.versionfileThe project version is now read from
.versionat the repo root rather than fromgit describe. Previously,git describereturned sentinels (GITDIR-NOTFOUND, etc.) for tarball downloads, shallow clones, and no-tag builds, and the version-parsing regex would silently produce empty strings. With.versionas the source of truth, tarball downloads from GitHub now report the correct release version.git describeis still consulted, but only to enrich the runtimeROSS_VERSIONstring with a-N-g<sha>-dirtysuffix on developer builds.Formal release process and changelog
Added
Documentation/RELEASE_PROCESS.mddocumenting the release workflow end-to-end: how to cut a release, what gets tagged, what gets pushed where. Previously this was tribal knowledge and happened by tagging master with release notes written ad hoc on GitHub.Also added a changelog-fragment system:
CHANGELOG.mdat repo root accumulates per-release notesDocumentation/dev/holds per-PR fragment files named<slug>.<category>.md(categories:feature,bugfix,removal,build,misc; breaking changes marked inline with**[Breaking]**)scripts/compile-changelog.shcompiles pending fragments into a new CHANGELOG section at release timeTwo main wins: zero merge conflicts on changelog entries (each PR writes its own file(s)), and release notes become a review artifact rather than something written hastily at tag time. Fragments for PRs #197 and #198 are included retroactively so the v9.0.0 release notes will be complete.
The PR template (
.github/PULL_REQUEST_TEMPLATE.md) is also refreshed: TravisCI references gone, changelog-fragment requirement added.Checklist
-Walland-WextraDocumentation/dev/, unless the change is invisible to anyone outside the PR (test refactors, internal renames, comment-only tweaks)