You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
tag @main as of when this work begins as @v1
update all RAPIDS uses of these actions to @v1
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.
Description
Across RAPIDS CI today, projects pin to
@mainof this repo, like this:(rapidsai/cudf - .github/workflows/pr.yaml)
That makes the choices for merging breaking changes here painful:
mainhere (what I did for check_nightly_success: limit to PR target branch #94)@mainafter merging hereWe should instead publish versioned tags here and pin to those tags.
Benefits of this work
Makes breaking changes less costly:
mainimmediatelyAnd 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
@mainApproach
@mainas of when this work begins as@v1@v1@v1tag should be updated after non-breaking changes are merged@v2should be created when breaking changes are mergedWhat 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