release.yml: maintain floating major.minor tags automatically

[TMHSDigital]

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.7

Context

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.yml lines 23-27
• Session D D-0 audit transcript
• Phase 2 design doc Q9 (action pinning policy)

[TMHSDigital]

Adding context: PR #19 introduces a second composite action (release-doc-sync) that uses the same major-floating-tag pinning pattern as drift-check. After PR #19 merges, the meta-repo will have two floating tag families to maintain:

• v1.7 -> latest 1.7.x (for drift-check@v1.7)
• v1.0 -> latest 1.x.y (for release-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.$MINOR after 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:

1. Action-level metadata file (e.g., .github/actions/release-doc-sync/.tag-policy containing major-floating: true) that release.yml reads to decide which floating tags to maintain.
2. Maintain BOTH vMAJOR and vMAJOR.MINOR floating 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.7 keep getting the patch-train behavior; the new release-doc-sync@v1.0 consumers get major-floating; and a hypothetical consumer pinning @v1 would also work.

Phase 2a creates the v1.0 tag manually (per the user-approved sequencing). This issue stays open until the automation lands.