start v24.09.00 development [skip ci]

[jameslamb]

#163 added support for legate / cunumeric 24.09 nightlies here.

This PR proposes the following:

• starting to version legate-boost packages as 24.09.00dev{n}
• updating the instructions for releasing
• minor adjustments to how we pin to legate / cunumeric packages

Notes for Reviewers

See inline comments for explanations of these changes.

[jameslamb]

After merging #169, I tried to follow these instructions. They don't work because the current branch permissions in this repo don't allow me to push directly to main.

remote: Resolving deltas: 100% (1/1), completed with 1 local object.
remote: error: GH013: Repository rule violations found for refs/heads/main.
remote: Review all repository rules at https://github.com/rapidsai/legate-boost/rules?ref=refs%2Fheads%2Fmain
remote: 
remote: - Changes must be made through a pull request.
remote: 
remote: - Required status check "pr-builder / run" is expected.
remote: 
To github.com:rapidsai/legate-boost.git
 ! [remote rejected] main -> main (push declined due to repository rule 

Honestly... that's a good thing. This PR proposes a different way to update the development version without accidentally publishing e.g. the first 24.09.00 package with a version like 24.06.01dev{n}.

It proposes:

1. opening a PR like this one
2. adding [skip ci] to the end of the title, so merging it to main won't trigger a new branch build on main
3. manually pushing a tag like v24.09.00dev to main after merging

I'm going to be out until Monday... so @seberg @RAMitchell if you merge this while I'm out, can you please then immediately push a tag like that to main?

[jameslamb]

*_gpu = "ends with _gpu"

*_gpu* = "contains _gpu somewhere"

I think we want that slightly more flexible form, as there's no guarantee that the packages we install will always end with _gpu (even if the packages we currently build do).

Look at the diff from the PR that added these build string components to legate packages... there are some other things at the end of the build strings sometimes: https://github.com/nv-legate/legate.core.internal/pull/1164/files

[jameslamb]

🎉 https://github.com/nv-legate/legate.core.internal/pull/1164/files

[seberg]

LGTM, thanks.

[jameslamb]

Looks like the [skip ci] approach worked! No new build was triggered when this was merged to main: https://github.com/rapidsai/legate-boost/actions/workflows/build.yaml

Then I pushed a new tag to the repo, following these docs.

git checkout main
git pull upstream main
git tag -a v24.09.00dev -m "v24.09.00dev"
git push upstream v24.09.00dev

https://github.com/rapidsai/legate-boost/releases/tag/v24.09.00dev

That also did not trigger a new build, because of this regex that says "only do a new build on tags of releases"

legate-boost/.github/workflows/build.yaml

Lines 13 to 15 in 166c98d

	# run on pushes of new release tags
	tags:
	- v[0-9][0-9].[0-9][0-9].[0-9][0-9]

I'd copied that regex from other RAPIDS repos (e.g. this cudf example). There, it serves the purpose "don't run a new build when a non-release tag is pushed".

But I think here in this repo, since we'll now use a PR with [skip ci] in the commit message, we really do want to trigger the build job on any tag push. Otherwise, it'd take a PR like this one and then a second PR to get the first new packages produced. I'll push a follow-up with changes like that.

[jameslamb]

I just deleted that v24.09.00dev tag, in place of a v24.09.00.dev tag on the same commit.

git checkout main
git pull upstream main
git tag -d v24.09.00dev
git tag -a v24.09.00.dev -m "v24.09.00.dev"
git push upstream v24.09.00.dev

To match the way that cunumeric and legate are versions, where the version ends with a .dev{n}.

I'm updating the packaging stuff for this repo to reflect that, in #173.