What is the work-flow in RAPIDS? In NumPy we merge fixes to main first (unless they don't apply). Which is fine, but could add, something like "if the hotfix was not backported from main".

In RAPIDS, no developer ever targets a main branch directly. RAPIDS projects one long-lived branch per release (e.g. branch-24.10, branch-24.12).

Changes on those release branches are not merged to main until the entire branch is released.

A hotfix to the 24.10 release after work on the 24.12 release has already begun means new pull requests targeting branch-24.10. Those are then merged to main, a new v24.10.01 tag is cut (pointing at a commit on main), and hotfix packages are released.

It's rare (I think) that we apply hotfixes more than 1 major release back (e.g., releasing a cudf==24.10.02 when there is already a stable cudf==24.12.00). But if we did, then those tags could point to commit IDs that exist on branch-24.10 but not on main.

Here, I'm proposing using a different, every-PR-targets-main approach for the following reasons:

• to avoid the pain of having long-lived release branches (until we find we need one, for hotfixes)
• to test out workflows to serve as an example for maybe changing the RAPIDS flow in the future: Simplify RAPIDS branching model build-planning#63
• for consistency with how cunumeric and legate operate

Great. I half thought I heard rumblings for rapids to switch to this branching model, but maybe I am hallucinating :).

So this does not include the .dev, but the .dev part is found via the tag/branch?

Right, it's expected to be found via the tag.

This is what RAPIDS does, see https://github.com/rapidsai/cudf/tags

And it's how legate is doing it too: https://github.com/nv-legate/legate.core.internal/tags

Sorry, I'm struggling today to remember exactly why that's preferable to including the dev part in the file or in the code that calculates "number of commits since the last tag" to generate a version like 24.12.00dev5.

I suppose this sets the rapids-version above? (I think it's all good. I was just pausing now because for projects that also depend on RAPIDS, we may have to align the RAPIDS versions we use with the rapids-cmake version in legate.)

This is actually not related to the version of RAPIDS (e.g. the version used to pull in rapids-cmake), though I understand how the command names make it seem that way 😅

rapids-generate-version comes from here: https://github.com/rapidsai/gha-tools/blob/8bd8fca71b5fae38b1493c547d15e73da40b32e1/tools/rapids-generate-version

It's just a small shell script that computes a version string from git tags, like this:

dunamai_format="{base}"
if ! rapids-is-release-build; then
    # Nightlies include the distance from the last tag as the alpha version.
    dunamai_format="{base}{stage}{distance}"
fi

# Now change the version.
dunamai_version=$(python -m dunamai from git --format ${dunamai_format})

echo -n "${dunamai_version}"

I'm proposing using that tool to avoid duplicating that logic here in legate-boost.

The rapids-* prefix on all the tools from that repo is primarily intended to avoid conflicts with other tools (generate-version is a pretty generic name, for example)... it doesn't by itself mean that a particular tool does something RAPIDS-specific.