proposal: start versioning this repo?

Description

Across RAPIDS CI today, projects pin to @main of this repo, like this:

  check-nightly-ci:
    runs-on: ubuntu-latest
    steps:
      - name: Check if nightly CI is passing
        uses: rapidsai/shared-actions/check_nightly_success/dispatch@main

(rapidsai/cudf - .github/workflows/pr.yaml)

That makes the choices for merging breaking changes here painful:

• option 1: immediately merge a bunch of PRs across RAPIDS after merging one to main here (what I did for #94)
• option 2 open PRs in RAPIDS repos temporarily pinning them to a specific commit, then go open new ones pinning to @main after merging here
• option 3: just merge here and accept CI being broken in other repos until they adjust to changes

We should instead publish versioned tags here and pin to those tags.

Benefits of this work

Makes breaking changes less costly:

• reduced need for coordination and admin-merges across all of RAPIDS
• reduced need for in-progress PRs to update to latest main immediately

And reducing the cost of breaking changes should hopefully make it less likely we hold around backwards compatibility (complexity!) we otherwise don't want in this repo.

Acceptance Criteria

• this project uses versioned tags
• all RAPIDS repos refer to this repo by tags or commit SHAs, not @main

Approach

1. tag @main as of when this work begins as @v1
2. update all RAPIDS uses of these actions to @v1
3. add documentation here about the versioning, noting that:
   • the @v1 tag should be updated after non-breaking changes are merged
   • a new major-version tag like @v2 should be created when breaking changes are merged

What about minor versions?

Once we've moved RAPIDS repos away from using @main, the tag structure can follow any patterns we find useful. I (@jameslamb) personally think only updating tags for breaking changes is sufficient to minimize disruptions, and that it minimizes how often we have to do all-of-rapids updates of those tag references.

Notes

N/A

Start with the cited cudf .github/workflows/pr.yaml example and search RAPIDS repositories for uses of this repository pinned to @main. Review the proposed v1 tagging and documentation approach, then track the tag updates across RAPIDS. Done means versioned tags exist, RAPIDS references use tags or commit SHAs, and the versioning guidance is documented here.