Skip to content

proposal: start versioning this repo? #97

@jameslamb

Description

@jameslamb

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 check_nightly_success: limit to PR target branch #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

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions