fix(release): compute the next version from tags reachable from the branch

[joaodinissf]

Problem

release.yml computes the next version from the highest v* tag in the whole repository:

LATEST=$(git tag --list 'v*' --sort=-version:refname | head -1)

Releasing from a maintenance branch (for example v18.0.x after master has released v19.0.0) therefore computes the next version of master's line, v19.0.1 instead of v18.0.1. The "Verify feature.xml versions" step then always fails, because the branch's features are 18.0.x.

Fix

Only consider tags reachable from the commit being released:

LATEST=$(git tag --list 'v*' --merged HEAD --sort=-version:refname | head -1)

The job checks out inputs.branch with fetch-depth: 0, so every tag is available to --merged.

Reproduction

A throwaway repository with v18.0.0 and v19.0.0 on master and a v18.0.x branch cut from v18.0.0:

branch=master   old=v19.0.0  new=v19.0.0
branch=v18.0.x  old=v19.0.0  new=v18.0.0

• Master: the result is unchanged.
• Maintenance branch: it now continues its own tag line.

Scope and limits

• Maintenance releases still don't work end to end. Maintenance-branch builds also fail the Tycho baseline gate, because baseline.repo.url points at the highest release overall. That's a separate fix.
• Possible tag collision on master: a master patch release could collide with an existing tag if a maintenance branch shared master's current major.minor. In that case, bump the minor instead. Maintenance branches are normally cut from older lines.
• Not linted: the workflow wasn't checked with actionlint, because it isn't available locally.

Found by the formal model of the release pipeline in #1549 (formal/BUGS.md, PIPE-2): both the TLA+ and the Lean model reach this state, and 3/3 independent reviewers upheld it.

🤖 Generated with Claude Code