rapidsai / legate-boost

GBM implementation on Legate
https://rapidsai.github.io/legate-boost/
Apache License 2.0
8 stars 6 forks source link

reduce hard-coding of version #135

Closed jameslamb closed 1 month ago

jameslamb commented 1 month ago

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 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.