Make GitVersion ignore tags; bump next-version to 1.1.0#89
Merged
Conversation
…1.1.0 The previous pipeline used GitVersion's CommitsSinceVersionSource, which treats any matching version tag (e.g. v1.0.273) as the version source. That made the patch number reset whenever such a tag was created, so the latest build went from 1.0.273 back down to 1.0.82. Compute Major.Minor directly from next-version in GitVersion.yml and the patch number as the count of commits since that file was last modified. The version is now tag-independent and monotonically increasing within a release line. Also bump next-version to 1.1.0 so new builds start at 1.1.x, comfortably above the previous 1.0.273 high-water mark.
sevoku
approved these changes
May 20, 2026
Contributor
There was a problem hiding this comment.
Pull request overview
This PR changes the build/versioning strategy so CI-generated versions are derived solely from GitVersion.yml (ignoring git tags), and bumps the release line to 1.1.x via next-version: 1.1.0.
Changes:
- Update
GitVersion.ymldocumentation and bumpnext-versionto1.1.0. - Replace GitVersion tool invocation in GitHub Actions and OneBranch pipelines with parsing
next-version+ counting commits sinceGitVersion.ymllast changed. - Remove GitVersion from the local dotnet tool manifest.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| GitVersion.yml | Documents the new tag-independent scheme and bumps next-version to 1.1.0. |
| .pipelines/CosmosDB-Shell-Official.yml | Computes version from GitVersion.yml + git commit count (replacing dotnet-gitversion). |
| .github/workflows/validate-and-package.yml | Computes version properties in CI using the new GitVersion.yml-based logic and removes GitVersion tool restore. |
| .config/dotnet-tools.json | Drops gitversion.tool from the local tool manifest. |
…bump to 1.1.0" This reverts commit 0ed2b3c.
…o 1.1.0 Override GitVersion's 'strategies' list to omit TaggedCommit so tags such as 'v1.0.273' no longer reset CommitsSinceVersionSource. The previous behavior caused the build version to go backwards (1.0.273 -> 1.0.82) after the tag was created. Also bump next-version to 1.1.0 so new builds start at 1.1.x, comfortably above the previous 1.0.273 high-water mark. Locally GitVersion now reports 1.1.357 on this branch.
mkrueger
changed the title
sevoku
approved these changes
May 20, 2026
mkrueger
added a commit
that referenced
this pull request
May 20, 2026
…r.Minor) (#90) ## Why PR #89 made the build version independent of git tags by removing the `TaggedCommit` strategy from `GitVersion.yml`. That fixed the regression where tagging `v1.0.273` reset the patch to `82`. However, GitVersion's `ConfiguredNextVersion` strategy returns `next-version` from the config file but **does not set a base version SHA**, so `CommitsSinceVersionSource` falls back to counting all commits in the repository. Result: after merging #89, builds show `1.1.357+` instead of starting at `1.1.0` after the `next-version` bump. The patch never resets when `next-version` is bumped, which makes a `Major.Minor` bump indistinguishable from any other commit. ## What Keep GitVersion responsible for parsing/validating `Major.Minor` from `GitVersion.yml`, but compute the patch in both pipelines from the commit history of `GitVersion.yml` itself: ```pwsh $configCommit = (git log -n 1 --format=%H -- $configPath).Trim() $patch = [int](git rev-list --count "$configCommit..HEAD") ``` Applied identically in: - `.github/workflows/validate-and-package.yml` - `.pipelines/CosmosDB-Shell-Official.yml` ## Behavior - Tag-independent (matches the goal of #89). - Patch resets to `0` whenever `GitVersion.yml` is edited (e.g. when bumping `next-version`). - Subsequent commits after a bump produce `1.1.1`, `1.1.2`, … in order. - The next bump (say to `1.2.0`) automatically resets the counter back to `0`. Note: the very first build after this PR merges will be `1.1.<small>` rather than literally `1.1.0`, because the merge commit and any commits between #89 and this PR are counted from `GitVersion.yml`'s last edit (commit `319b304` from #89). Future `next-version` bumps will reset cleanly because they touch `GitVersion.yml`. ## Validation ```text GitVersion Major.Minor: 1.1 Config commit: 319b304 Final version: 1.1.<commits-since-bump> ``` `dotnet build CosmosDBShell/CosmosDBShell.csproj` succeeds locally.
mkrueger
added a commit
that referenced
this pull request
May 21, 2026
Converts the `Unreleased — since v1.0.273` section to `1.1.4 — 2026-05-21` (first release on the 1.1 line) and adds entries for the PRs that landed after #86 (the last CHANGELOG update): - **Highlights / New features:** multi-line REPL input with `\` continuation and parser-driven incomplete-input detection ([#88](#88)); parser & query diagnostics with line, column, source caret, and "Did you mean…" suggestions ([#87](#87)). - **Documentation:** notes that [docs/navigation.md](docs/navigation.md) and [README](README.md) now document multi-line input. - **Build & pipeline:** versioning moved to [Nerdbank.GitVersioning](https://github.com/dotnet/Nerdbank.GitVersioning); local builds now produce the same versions as CI ([#90](#90), [#91](#91)). PR #89 was a stepping stone superseded by the NBGV migration, so it isn't called out separately. Docs-only change — no code touched.
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.
Why
The latest build dropped from
1.0.273back to1.0.82. Root cause: GitVersion's defaultstrategieslist includesTaggedCommit, which picks any matching version tag (e.g.v1.0.273) as the "version source" and resets the commit count from there. Oncev1.0.273was tagged, the patch counter snapped back from 273 to "commits since that tag" (= 82), so the next build was lower than the previous one.What
Single change: in
GitVersion.yml, override thestrategieslist to omitTaggedCommit, and bumpnext-versionto1.1.0.GitVersion now never considers any tag as a version source, so the build version depends only on
next-version(forMajor.Minor) and commit count (for the patch). The pipeline scripts and tool manifest are unchanged.Properties of the new scheme
1.1.xis strictly greater than any earlier1.0.xvalue, including1.0.273.next-versionis still the supported way to start a new release line.Verification
dotnet tool run dotnet-gitversionreports1.1.357(357 =CommitsSinceVersionSource, no tagged-commit source picked).GitVersion.yml.