ci(release): support release/* branches with version-comparison gating by ericallam · Pull Request #3530 · triggerdotdev/trigger.dev

Lets us ship a patch (e.g. 4.4.6) from a release/4.4.x branch without
including unreleased work merged into main, and without the patch
clobbering floating tags incorrectly.

The release-pipeline pieces this touches and how each behaves now:

  npm dist-tag        latest if version > current latest, else release-<M.m>
  Docker :v4-beta     same gate (highest version only)
  Docker :release-X.Y new per-line floating tag, always set on a semver build
  GitHub release      --latest=true|false set explicitly (no auto-detect)

How the gate is computed:
  release.yml's 'Compare new version to current latest' step queries
  npm view @trigger.dev/sdk dist-tags.latest, compares via sort -V,
  sets is_latest=true|false. Drives every floating tag.

Triggers / refs:
  - pull_request:branches[main, release/**]
  - if-conditions allow head.ref starting with 'changeset-release/'
  - workflow_dispatch ref must be reachable from main OR a release/* branch
  - changesets-pr.yml fires on push to release/** too; PR-enhance step
    discovers source branch dynamically (no more hardcoded changeset-release/main)

Other changes:
  - gh release create: drop --target main (tag carries right commit)
  - dispatch-changelog payload includes is_latest so the marketing site
    can render lagged-line releases differently
  - enhance-release-pr.mjs prepends a Release prep header on release/*
    branches showing version, current latest, and whether the PR will
    take the latest dist-tag

release-helm.yml unchanged — already creates as draft+prerelease so it
can't claim Latest. publish-worker.yml (coordinator/provider) unchanged
since those don't have a :v4-beta-equivalent floating tag.

Validated end-to-end in ericallam/pkgring-sandbox across both scenarios:
  Scenario A (lagged hotfix): latest stays put, only release-X.Y moves
  Scenario B (main has unreleased work, hotfix is highest): latest moves