--generate-notes uses the commit graph, not semver ordering

[derekmisler]

Summary

GitHub's --generate-notes flag determines the range of commits to include in release notes by walking the commit graph from the new tag back to the previous reachable tag — it does not use semver ordering. This means if tags exist out of semver order in the graph, the generated notes can be incorrect or empty. This PR explicitly passes --notes-start-tag with the previously detected tag so the release note range is always correct and predictable.

Changes

• .github/workflows/release.yml: Captures the previously detected tag (LATEST_TAG) as a step output (previous), then conditionally passes --notes-start-tag "$PREVIOUS" to gh release create when a previous tag exists, ensuring release notes always cover exactly the commits since the last release.

How to Test

• Trigger the release workflow and verify the generated GitHub Release notes contain only commits made since the previous tag, not a broader or empty set.
• Check the workflow logs for the updated New version: X.Y.Z (previous: vA.B.C) line to confirm the previous tag is being detected and passed through correctly.
• For a first-ever release (no previous tag), confirm the workflow still succeeds — the --notes-start-tag argument is omitted when PREVIOUS is empty.

[derekmisler]

/describe

[docker-agent]

✅ PR description has been generated and updated!

[docker-agent]

Review Summary

This PR improves the release notes generation by explicitly specifying the previous tag using --notes-start-tag. The implementation is well-structured and follows bash best practices:

✅ Correct array handling: ARGS=() declaration and "${ARGS[@]}" expansion are proper
✅ Safe conditional logic: [ -n "$PREVIOUS" ] correctly checks for non-empty values
✅ Proper quoting: Variables are quoted to prevent word splitting
✅ Fallback handling: The conditional ensures the flag is only added when a previous tag exists

No issues found. This change looks good!