Bump vnext version line to 2.1

[Tyrie Vella (tyrielv)]

Problem and Context

The vnext branch integrates the next minor release. The master branch is the 2.0 line, and releases come from master.

Today both branches set GVFSMajorAndMinorVersion to 2.0 in .azure-pipelines/release.yml. A build from vnext gets a 2.0.<revision> version. It looks the same as a 2.0 servicing build.

A different minor version also lets a client read the version number to see if an installed build has features that exist only on the next minor line. This PR does not add such a feature.

Changes

• Change GVFSMajorAndMinorVersion from 2.0 to 2.1 in .azure-pipelines/release.yml. This is the only place that sets the value. GVFSVersion reads it from there.

[Nathan Baird (ShiningMassXAcc)]

Reviewed the change and traced what consumes the version. No blockers — the change is correct and the reasoning in the description holds up. Comments below are about keeping it durable rather than about the value itself.

What I verified, for the record:

• "This is the only place that sets the value" checks out — only the definition and the $(GVFSVersion) consumer reference it, and there is no other hardcoded 2.0 in a shipping path. Version.props carries an independent dev default (0.2.173.2).
• The version shape is unchanged: 2.1.<revision> keeps the same four-part form as the shipped 2.0.26259.1.
• Nothing gates a client on major/minor — ServerGVFSConfig only carries cache servers — so there is no compatibility edge here.
• The installer keeps a fixed AppId with no version-keyed logic, so a 2.1 build installs as an ordinary in-place upgrade.
• The release task publishes with isDraft: true and isPreRelease: true, so a 2.1 build cannot become the GitHub "Latest" release.
• upgrade-tests.yaml resolves its LKG through releases/latest, which excludes pre-releases, so vnext builds cannot become the upgrade baseline.

Plus one inline comment on the changed line, and the following.

---

How does this bump reach a shipping release? vnext has never been merged back to master in this repo's history, and releases/shipped currently snapshots master. If promotion is a merge, 2.1 travels along automatically. If it is a cherry-pick or squash of the feature commits, this bump gets left behind, and a release that does contain the vnext work would still be versioned 2.0.x. Worth stating the intended promotion step in the PR description so the next person does not have to infer it.

---

Nothing in the repo documents the version-line model. No Markdown file in the tree mentions vnext at all, so this PR description is the only record. AGENTS.md already carries release and version facts (the "What ships in a public release" section, Version.props / MinimumGitVersion), which makes it a natural home for a couple of lines: vnext builds 2.1.x, master and releases/shipped build 2.0.x, and the value lives in .azure-pipelines/release.yml.

---

Nothing in CI exercises this file. release.yml is trigger: none / pr: none, and no workflow under .github/workflows references .azure-pipelines/. The green checks on this PR are build and functional tests, which never parse it. Has the release pipeline been queued against this branch (or vnext) to confirm it produces a 2.1.<revision> version and a matching v2.1.<revision> tag? A one-off manual run would be enough — mainly to confirm nothing downstream assumes the 2.0. prefix.

---

Minor, adjacent: release-winget.yaml triggers on release: types: [released], which does not fire for pre-releases, and the pipeline creates the release as a draft pre-release — so vnext builds are safe today. The only thing keeping a 2.1 build out of winget is that whoever publishes remembers to leave the pre-release flag set. Now that two version lines can produce draft releases in the same repo, a guard on the workflow (or a note in the release runbook) might be worth it.

---

Unrelated to this diff, spotted while tracing the above — happy to move this to its own issue. In .github/workflows/release-winget.yaml:

$version = $github.release.tag_name -replace ".v",""

-replace takes a regex, and . matches any character, so the pattern requires a character before the v. For a tag like v2.0.26229.1 the leading v has nothing before it, so nothing is stripped and $version keeps its v, despite the comment saying "Remove 'v' from the version". -replace '^v','' is the intended behaviour.

[Nathan Baird (ShiningMassXAcc)]

Marking this as the GitHub equivalent of "waiting for author" — this is not a rejection, and there is no blocking correctness concern in the change itself.

The one substantive ask is the inline comment on .azure-pipelines/release.yml: a short comment anchoring why vnext carries 2.1, so that a future master → vnext merge conflict on that line cannot quietly resolve back to 2.0 and undo this change.

The rest are questions rather than change requests — the promotion path for the bump, where the version-line model belongs in docs, and whether the release pipeline has been run once to confirm a 2.1.<revision> build and tag. Answers are fine; they do not all need code changes.

Happy to clear this as soon as you have replied.