feat(duo): lock Duo CLI auto-updates to compatible major version

Kai Armstrongrequested to merge
feature/duo-cli-major-version-lock into main

What does this MR do and why?

Adds a duoMaxCompatibleMajorVersion constant that bounds Duo CLI auto-updates to the approved major version. When the latest release in the package registry has a higher major version than supported, glab blocks the update and notifies the user to upgrade glab first.

Closes #8230 (closed)

How to set it up

The constant lives in internal/commands/duo/cli/cliutils/binary_manager.go:

// duoMaxCompatibleMajorVersion is the maximum Duo CLI major version this build of glab
// supports. Auto-updates are bounded to this major version. When Duo CLI releases a new
// major version, glab must be updated to increment this value after validating compatibility.
duoMaxCompatibleMajorVersion = 8

When Duo CLI ships a new major:

  1. Duo team notifies glab team
  2. glab team validates compatibility and bumps duoMaxCompatibleMajorVersion
  3. New glab ships — users who update glab receive the new Duo major on next check
  4. Users on older glab are protected and continue on their current version

Changes

binary_manager.go

  • Add duoMaxCompatibleMajorVersion = 8 constant
  • Replace latestPackageOptions + getLatestVersion with fetchLatestPackage (fetches per_page=1 — sufficient since Duo CLI releases linearly on one major at a time, confirmed by release history)
  • CheckForUpdate gains a newMajorVersion return value (non-empty when the latest release exceeds the supported major)
  • fetchPackageAsset blocks install/update when the latest package is an incompatible major
  • Removed strings.TrimPrefix on version strings — hashicorp/go-version handles the v prefix natively

cli.go

  • updateCheckResult gains newMajorVersion string
  • Background update check and --update both surface a "requires newer glab" notice when a new major is detected

binary_manager_test.go

  • Replace removed scanVersions tests with TestDuoMaxCompatibleMajorVersion — table-driven tests verifying the version boundary logic against the hashicorp/go-version library

MR acceptance checklist

  • This MR does not have a documentation impact
  • I have added tests, or tested this manually (or both)
  • I have followed the contributing guidelines

Merge request reports