Repository navigation
release.yml: maintain floating major.minor tags automatically #14
Description
The composite action at .github/actions/drift-check/action.yml documents that tool repos should consume @v1.7 (or similar major.minor floating tags). However, release.yml only creates the specific patch tag (v1.7.3, v1.7.4, etc.).
The v1.7 floating tag was created manually for the v1.7.x rollout (Phase 2 Session D). For future major.minor bumps (1.8.0, 1.9.0, etc.), release.yml should automatically maintain the corresponding floating tag.
Implementation sketch
When release.yml creates v$VERSION, also force-update v$MAJOR.$MINOR to point at the same SHA. Roughly:
TAG="v$VERSION"
MAJOR_MINOR=$(echo "$VERSION" | cut -d. -f1-2)
FLOATING_TAG="v$MAJOR_MINOR"
git tag -a "$TAG" -m "Release $TAG"
git push origin "$TAG"
git tag -f "$FLOATING_TAG" "$TAG"
git push -f origin "$FLOATING_TAG"(Force-push of the floating tag is intentional and expected.)
Testing
After implementing, cut a small no-op release (e.g., docs PATCH bump). Verify v1.7 ref moves to the new SHA:
gh api repos/TMHSDigital/Developer-Tools-Directory/git/refs/tags/v1.7Context
Filed during Phase 2 Session D D-0 audit. Not blocking the v1.7.x rollout (manual tag creation works for one release cycle), but should be addressed before the next MINOR bump (1.8.0) to avoid another manual step. Also relevant if future MAJOR bumps want a v1 floating tag for callers willing to accept across-MINOR drift (probably not — MAJOR.MINOR is the right granularity per the standards versioning policy).
Related
- Composite action contract:
.github/actions/drift-check/action.ymllines 23-27 - Session D D-0 audit transcript
- Phase 2 design doc Q9 (action pinning policy)
Activity
TMHSDigital commentedon Apr 25, 2026
Adding context: PR #19 introduces a second composite action (
release-doc-sync) that uses the same major-floating-tag pinning pattern asdrift-check. After PR #19 merges, the meta-repo will have two floating tag families to maintain:v1.7-> latest1.7.x(fordrift-check@v1.7)v1.0-> latest1.x.y(forrelease-doc-sync@v1.0, broader because the action's contract changes less frequently than the drift checker's)The implementation sketch in this issue still works (force-update
v$MAJOR.$MINORafter the patch tag), but it would need to also handle a separate "broader" floating tag for actions that pin at the major level. Two options:.github/actions/release-doc-sync/.tag-policycontainingmajor-floating: true) thatrelease.ymlreads to decide which floating tags to maintain.vMAJORandvMAJOR.MINORfloating tags on every release; consumers pick the granularity they want. Cheap and uniform.Option 2 is probably simpler. Tool repos that consume
drift-check@v1.7keep getting the patch-train behavior; the newrelease-doc-sync@v1.0consumers get major-floating; and a hypothetical consumer pinning@v1would also work.Phase 2a creates the
v1.0tag manually (per the user-approved sequencing). This issue stays open until the automation lands.fix: release.yml tag introspection and add floating tag automation (#26)