[sbokatuk]

Releasing 7.1.5.5 and 6.1.6.5 moved the GitHub Latest label from v8.1.3.1 to v6.1.6.5. gh release create sends no make_latest, and GitHub then gives Latest to the newest release whatever its version. The next older-track release would do the same.

Before creating the release, this now reads the current Latest and passes --latest=false when the new version sorts behind it. Releases at or ahead of Latest send nothing new, so they behave as before.

It compares with Latest rather than using default-track because that output reads the tagged commit. A tag cut from an earlier commit after the default has moved on would still report true. It compares with Latest rather than every release because the legacy v8.1.7.3 sorts above everything current.

If Latest can't be read, the flag is left off and GitHub's own choice stands. The packages are already on nuget.org by this step, so it must not fail the job.

The label itself was already put back by hand with gh release edit v8.1.3.1 --latest. This PR adds no release note, so merging it releases nothing.

Checked

The real lines from release.yml under bash -e, with a stub gh:

Current Latest	New version	Flags added
v8.1.3.1	7.1.5.6, 6.1.6.6, 8.1.2.6	--latest=false
v8.1.3.1	8.1.3.2, 8.1.4.1	none
v8.1.4.1	8.1.3.2	--latest=false
v8.1.9.1	8.1.10.1	none
v8.1.10.1	8.1.9.1	--latest=false
v8.1.3.1	8.1.4.1-rc.1	--prerelease
v8.1.3.1	7.1.5.6-rc.1	--prerelease --latest=false
unreadable	8.1.3.2	none

gh release view --json tagName --jq .tagName against this repository returns v8.1.3.1, and the workflow file still parses as YAML.

Not checked

• release.yml doesn't run on a pull request, so this first runs on GitHub at the next release of any track. After it, gh api repos/sbokatuk/FFmpegKit.Android/releases/latest should name the highest version.
• sort -V ran on macOS here, and the job uses GNU sort on ubuntu-latest.
• Two releases created in the same few seconds could still race, because nothing serialises them. It would take two different versions ahead of Latest at once, which the release-note flow doesn't produce, so this adds no lock.

This is also the first CI run with #24 and #25 together. They were never tested as a pair before landing.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

Latest eligibility is based on the tagged commit, allowing older or out-of-order releases to overwrite the Latest label.

1 open issue

• Prevent older releases from overwriting the Latest label · New

What changed in this PR

This PR aims to keep older FFmpeg tracks from taking GitHub’s Latest label by reusing the release workflow’s existing default-track output.

Changes:

• Adds --latest=false when default-track is not true, leaving default-track behaviour unchanged.
• Documents why older tracks must opt out of Latest.

File	Description
.github/​workflows/​release.yml	Adds conditional Latest-label opt-out and explanatory comments.

_{Review effort: Balanced}