Proposes single-sourcing the version for this project in a text file, VERSION, at the root of the repo. This practice has been very helpful in other RAPIDS libraries, to ensure that versions are consistent across a variety of locations, including:
wheels
conda packages
CMake project
docs site
And there's already such an inconsistency here in legate-boost.
For more discussion on this practice, see https://github.com/rapidsai/build-planning/issues/15. Thanks to @KyleFromNVIDIA for pushing changes like this across RAPIDS... I've borrowed a lot from his PRs for this one.
Notes for Reviewers
Why v0.1.0?
I know @RAMitchell and I had talked previously about using a calver version that matches legate-core (e.g., legate-boost=24.06.00 would depend on legate-core=24.06.00 and cunumeric=24.06.00).
Proposing we defer that in a follow-up PR, alongside setting up versioning + publishing of nightlies. Keeping the version at 0.1 here means any calendar-based version we add in the future will end up being newer than any packages published from now until then.
Contributes to #115.
Proposes single-sourcing the version for this project in a text file,
VERSION
, at the root of the repo. This practice has been very helpful in other RAPIDS libraries, to ensure that versions are consistent across a variety of locations, including:And there's already such an inconsistency here in
legate-boost
.https://github.com/rapidsai/legate-boost/blob/f58dbe8c1aae114c7ddfbb1f228197c9149e2671/pyproject.toml#L12
https://github.com/rapidsai/legate-boost/blob/f58dbe8c1aae114c7ddfbb1f228197c9149e2671/CMakeLists.txt#L3
For more discussion on this practice, see https://github.com/rapidsai/build-planning/issues/15. Thanks to @KyleFromNVIDIA for pushing changes like this across RAPIDS... I've borrowed a lot from his PRs for this one.
Notes for Reviewers
Why v0.1.0?
I know @RAMitchell and I had talked previously about using a calver version that matches
legate-core
(e.g.,legate-boost=24.06.00
would depend onlegate-core=24.06.00
andcunumeric=24.06.00
).Proposing we defer that in a follow-up PR, alongside setting up versioning + publishing of nightlies. Keeping the version at 0.1 here means any calendar-based version we add in the future will end up being newer than any packages published from now until then.