[Feature Request] Expose BaseSemVer as Output Variables

[jakublatkowski]

Expose BaseSemVer in the output variables so CI pipelines can reference the base version.

Context

Some systems (e.g., SonarCloud) use semantic versioning to compare incremental code coverage. They require the previous (base) version to generate accurate incremental coverage reports.

Possible Implementation

Include BaseSemVer alongside existing version fields in the standard outputs (environment variables, JSON output, and any other supported output channels), enabling CI pipelines to consume it directly.

Motivation

Simplifies integrations that need the base version, avoiding custom parsing or brittle workarounds.

Contribution

I already have changes in my fork and I’m happy to open a PR if this addition is considered valuable.

[arturcic]

@jakublatkowski I guess we could at least have a look on a draft PR and understand better the motivation behind the changes

[jakublatkowski]

Thanks for the feedback! I've created a draft PR so you can see the implementation details and better understand the motivation behind the changes. Would appreciate your thoughts when you get a chance to review it.

#4804

[HHobeck]

@jakublatkowski first of all I want to thank you for your ambition and the time you are investing in this project.

For me the motivation is still vague and not comprehensible. In the PR you mentioned following use cases:

• Incremental Analysis Tools
• Release Comparisons
• Documentation & Reporting
• Multi-stage Pipelines

Maybe we can go to each use case and discuss them?

I have started a discussion with AI and try to understand the first use case with SonaCloud.

Outcome of the AI discussion for the first use case:

You are correct: BaseSemVer ≠ “previous version”

In GitVersion terms:

• BaseSemVer is the base version GitVersion selected
• That base can come from:
  • the last tag
  • the last pre-release tag
  • the merge message or
  • the release branch name
• It is not guaranteed to be:
  • the immediately previous released version or
  • even a version that ever existed as a tag

So yes — BaseSemVer is not a reliable “previous version” key.

That means:

• The PR description overclaims what BaseSemVer guarantees.

Implication for SonarCloud (this is the key point)

BaseSemVer cannot reliably map to:

• “the previous SonarCloud analysis I should diff against”

So your criticism is 100% valid:

• Using BaseSemVer does not solve the “previous version” problem in general.

At best, it solves:

• “Give me a stable version string across pre-release builds.”

And even then:

• it may collapse multiple release lines onto the same version
• which can also confuse SonarCloud baselining

How this should be framed in a serious review

If I were you, I’d push back with something like:

The PR description implies BaseSemVer can be used as “the previous version” for tools like SonarCloud. This is not guaranteed, as BaseSemVer may remain constant across major/minor increments and does not necessarily correspond to a released or previously analyzed version.

The value of this change seems to be exposing an internal, deterministic version anchor — not providing a reliable baseline identifier.

That’s a strong, technically accurate review comment.

[arturcic]

• Metadata Completeness: We already output the "Distance" (CommitsSinceVersionSource) and "End Result" (FullSemVer). Providing the "Start" (VersionSourceSemVer) completes the data needed to visualize the version range.

I like the way you've described it. I wonder if it's a good idea to actually name the variables that way. "Distance" is easier to read in my opinion

[jakublatkowski]

I guess it is up to you ;)

However, I think renaming the existing variables (CommitsSinceVersionSource, etc.) might introduce breaking changes as they are already exposed and likely in use.

That is why I named the new one VersionSourceSemVer to correspond with the naming convention of the existing VersionSource variables.

If you are happy with this approach, I am happy to move the PR out of draft state for review. :D

[arturcic]

However, I think renaming the existing variables (CommitsSinceVersionSource, etc.) might introduce breaking changes as they are already exposed and likely in use.

I will leave it up to @HHobeck

[asbjornu]

I agree with the arguments given for adding VersionSourceSemVer. 👍🏼

[asbjornu]

Regarding renaming CommitsSinceVersionSource to VersionSourceDistance, I agree to this. The way we can do it in a backwards compatible way is to deprecate CommitsSinceVersionSource and add VersionSourceDistance, both exposing the same value for the rest of v6. Then in v7, we'll remove CommitsSinceVersionSource.

[HHobeck]

Would it be possible to output the increment as well? I would name the variable VersionSourceIncrement. What do you think?

[asbjornu]

How is VersionSourceIncrement different from CommitsSinceVersionSource?

[HHobeck]

The VersionSourceIncrement property gives the information about which increment has been used for the next version calculation. Possible values are:

• None
• Patch
• Minor
• Major

[asbjornu]

Aha, I see. Makes sense! 👍🏼

[jakublatkowski]

@arturcic @asbjornu @HHobeck

Thank you all for the feedback!

Based on the discussion, there are two additional features to consider:

Feature 1 - Rename CommitsSinceVersionSource to VersionSourceDistance:

• Deprecate CommitsSinceVersionSource
• Add new VersionSourceDistance property with the same value

Feature 2 - Add new VersionSourceIncrement property:

• Output the increment used for version calculation
• Possible values: None, Patch, Minor, Major

---

Should I include both features in this PR, or would you prefer separate PRs for each? They're both related to version source properties, but I'm happy to split them if that's preferred for review/tracking purposes.

[HHobeck]

Should I include both features in this PR, or would you prefer separate PRs for each? They're both related to version source properties, but I'm happy to split them if that's preferred for review/tracking purposes.

Would be fine with me if you put it into the actual PR.

[arturcic]

I added #4808, please add another issue for the second one. Please add separate PRs

[jakublatkowski]

@arturcic Thanks for merging my PR. What are the next steps to get it released? Should I wait until the milestone’s remaining work is complete, or would you like me to contribute to integrate it into the Azure DevOps (and other) tasks?

[arturcic]

Milestone is a wish list not a hard set. There is a PR I'm waiting for response from the author. If there is none by tomorrow, I will release version 6.6.0

[arturcic]

or would you like me to contribute to integrate it into the Azure DevOps (and other) tasks?

there is already a PR that exposes the new variable(s) GitTools/actions#1915 It will get merged when 6.6.0 is released

[jakublatkowski]

Thank you

[jakublatkowski]

I also wanted to know if I did everything right with VersionSourceSemVer...

Should it be already visible here: https://gitversion.net/docs/reference/variables

I can see that VersionSourceDistance is present, but in this release, you're mentioning both.

[arturcic]

it actually should get published on release, but i think i accidentaaly force pushed the doc updates

[HHobeck]

May I ask you: Would you be able to implement the following feature?

Feature 2 - Add new VersionSourceIncrement property:

• Output the increment used for version calculation
• Possible values: None, Patch, Minor, Major

[arturcic]

@HHobeck please create an Issue with the details, we can ask Copilot to make a draft and then we can improve it

[jakublatkowski]

I can take a look on that

[jakublatkowski]

#4814

[HHobeck]

Thank you @jakublatkowski for your contribution. I'm going to close this discussion