Infer version from tags/branches instead of Versions.props#37985
Merged
Conversation
Replace the eng/Versions.props-based version detection in the label-and-milestone-issues workflow with logic that infers versions from tags and branches present in the repo: - release/X.Y (servicing): list vX.Y.* tags via GitHub API, find the highest GA patch (< 100), set milestone to X.Y.(patch+1). No preview/rc label. - main: read only major.minor from Versions.props, then list release/X.Y-* branches to find the highest preview/rc branch. The next version is inferred: preview7→rc-1, rc1→rc-2, rc2→GA (no label). Milestone is X.Y.0. This fixes the issue where Versions.props was frequently updated too late and didn't represent the correct version at merge time. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Updates the issue labeling/milestoning automation to derive the version context from repository tags and branch names (rather than relying on eng/Versions.props at merge time), aiming to make version selection accurate even when Versions.props lags behind.
Changes:
- Replaces
Versions.props-based pre-release detection with logic that infers the target milestone/label from the PR’s base branch plus matching tags/branches. - For
release/X.Y, computes the next patch milestone from the highestvX.Y.*GA tag. - For
main, reads onlymajor.minorfromVersions.propsand infers the next preview/RC label from existingrelease/X.Y-*branches.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
| } | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
If no GA tags are found for the servicing branch (i.e., highestPatch stays -1), the computed milestone becomes X.Y.0, which is likely incorrect and may silently create the wrong milestone. It would be safer to fail fast (or handle the bootstrap case explicitly) when no matching vX.Y.Z tags are present, rather than defaulting to .0.
Suggested change
| if (highestPatch === -1) { | |
| throw new Error(`No GA v${major}.${minor}.Z tags found for servicing branch ${targetBranch}`); | |
| } |
AndriySvyryd
approved these changes
Mar 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace the
eng/Versions.props-based version detection in the label-and-milestone-issues workflow with logic that infers versions from tags and branches present in the repo:release/X.Y(servicing): ListsvX.Y.*tags via GitHub API, finds the highest GA patch (< 100), and sets milestone toX.Y.(patch+1). No preview/rc label.main: Reads onlymajor.minorfromVersions.props, then listsrelease/X.Y-*branches to find the highest preview/rc branch. The next version is inferred: preview7→rc-1, rc1→rc-2, rc2→GA (no label). Milestone isX.Y.0.This fixes the issue where
Versions.propswas frequently updated too late and didn't represent the correct version at merge time.