You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/input/docs/migration/v6-to-v7.md
+10Lines changed: 10 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,6 +44,16 @@ macOS.
44
44
45
45
Use `VersionSourceDistance` instead; it has the same value.
46
46
47
+
## Separate semantic and counting sources
48
+
49
+
Five additive output variables distinguish semantic provenance from counting: `SemVerSourceSemVer`, `SemVerSourceSha`, `SemVerSourceIncrement`, `CommitCountSourceSha`, and `CommitCountSourceDistance`. They are available in JSON, custom formats, generated version-information files, build-server output, and MSBuild.
50
+
51
+
Existing `VersionSource*` fields keep their values. `VersionSourceSha` identifies the counting anchor, which may not be the artifact supplying `VersionSourceSemVer`. The legacy `VersionSourceIncrement` can be `None` after candidate resolution even when an increment was applied; new integrations should use `SemVerSourceIncrement`.
52
+
53
+
For the removed v6 `CommitsSinceVersionSource`, `VersionSourceDistance` remains a compatible replacement; `CommitCountSourceDistance` is the explicit name for the same count. Do not replace that count with a distance from `SemVerSourceSha`: configuration and branch-name sources have no intrinsic SHA. New nullable source fields use JSON null; textual outputs use an empty string.
54
+
55
+
Update strict JSON property-set consumers for the five added fields. Public source interfaces and existing constructors remain available. This change does not alter candidate ordering, version numbers, or commit counts. See [version variables](/docs/reference/variables) for a concrete example.
56
+
47
57
## CLI Arguments - POSIX-style syntax
48
58
49
59
GitVersion now uses POSIX-style command-line arguments powered by System.CommandLine.
Use `CommitCountSourceDistance` when formatting the count, and `SemVerSourceSemVer` or `SemVerSourceIncrement` when describing the selected semantic baseline:
# Example: 5.0.0-None+002 for an external 5.0.0 baseline and two counted commits.
62
+
```
63
+
64
+
`SemVerSourceSha`can be absent for configuration or branch-name sources; it is not a substitute for `Sha` (HEAD) or `CommitCountSourceSha` (the counting anchor). Existing `VersionSource*` format names remain available for compatibility.
65
+
54
66
## Overview
55
67
56
68
The custom formatter functionality introduces several new formatters that can be used in GitVersion configuration files and templates:
@@ -50,7 +55,9 @@ Each property of the above JSON document is described in the below table.
50
55
|`AssemblySemFileVer`| Suitable for .NET `AssemblyFileVersion`. Defaults to `Major.Minor.Patch.0`. |
51
56
|`AssemblySemVer`| Suitable for .NET `AssemblyVersion`. Defaults to `Major.Minor.0.0` to allow the assembly to be hotfixed without breaking existing applications that may be referencing it. |
52
57
|`BranchName`| The name of the checked out Git branch. |
53
-
|`BuildMetaData`| The build metadata, usually representing number of commits since the `VersionSourceSha`. Despite its name, will not increment for every build. |
58
+
|`BuildMetaData`| The build metadata, usually representing number of commits since the `CommitCountSourceSha`. Despite its name, will not increment for every build. |
59
+
|`CommitCountSourceDistance`| Number of non-ignored commits reachable from HEAD but not from the counting anchor. A null anchor counts all reachable history. |
60
+
|`CommitCountSourceSha`| SHA of the counting anchor, or JSON null when counting all reachable history. |
54
61
|`CommitDate`| The ISO-8601 formatted date of the commit identified by `Sha`. |
55
62
|`CustomVersion`| A custom version configured with `custom-version-format`. Empty when no format is configured. |
56
63
|`EscapedBranchName`| Equal to `BranchName`, but with `/` replaced with `-`. |
@@ -67,20 +74,31 @@ Each property of the above JSON document is described in the below table.
67
74
|`PreReleaseLabel`| The full pre-release label, including the `PreReleaseNumber` when present. |
68
75
|`PreReleaseLabelWithDash`| The pre-release label prefixed with a dash. |
69
76
|`SemVer`| The semantic version number, including `PreReleaseLabelWithDash` for pre-release version numbers. |
77
+
|`SemVerSourceIncrement`| Final increment relative to the semantic baseline: `None`, `Patch`, `Minor`, or `Major`. |
78
+
|`SemVerSourceSemVer`| Baseline version supplied by the selected artifact or derivation. Mainline may use a folded baseline rather than a literal tag value. |
79
+
|`SemVerSourceSha`| SHA associated with the semantic source; JSON null for external sources such as configuration or a branch name. |
70
80
|`Sha`| The SHA of the Git commit. |
71
81
|`ShortSha`| The `Sha` limited to 7 characters. |
72
82
|`UncommittedChanges`| The number of uncommitted changes present in the repository. |
73
-
|`VersionSourceDistance`|The number of commits since the version source. |
74
-
|`VersionSourceIncrement`|The increment strategy used for the version calculation. Possible values:`None`, `Patch`, `Minor`, `Major`. |
75
-
|`VersionSourceSemVer`|The semantic version of the commit used as version source. |
76
-
|`VersionSourceSha`|The SHA of the commit used as version source. |
83
+
|`VersionSourceDistance`|Compatibility alias for `CommitCountSourceDistance`. |
84
+
|`VersionSourceIncrement`|Legacy increment metadata, preserved for compatibility. Prefer `SemVerSourceIncrement`; the legacy field can be`None` even when an increment was applied. |
85
+
|`VersionSourceSemVer`|Legacy semantic baseline. It need not correspond to `VersionSourceSha`; prefer `SemVerSourceSemVer`. |
86
+
|`VersionSourceSha`|Legacy counting-anchor SHA. Prefer `CommitCountSourceSha`, which represents an absent anchor as null. |
77
87
|`WeightedPreReleaseNumber`| A summation of branch specific `pre-release-weight` and the `PreReleaseNumber`. Can be used to obtain a monotonically increasing version number across the branches. |
78
88
79
89
Depending on how and in which context GitVersion is executed (for instance
80
90
within a [supported build server][build-servers]), the above version variables
81
91
may be exposed automatically as **environment variables** in the format
82
92
`GitVersion_FullSemVer`.
83
93
94
+
## Semantic and counting sources
95
+
96
+
The semantic source and counting anchor can differ. With a `1.0.0` tag followed by one commit and `calculation.next-version: 5.0.0`, the semantic baseline is `5.0.0` and `SemVerSourceSha` is null, while `CommitCountSourceSha` points to the `1.0.0` tag and `CommitCountSourceDistance` is 1. A `release/5.0.0` branch name can supply the same external baseline.
97
+
98
+
The distance remains available when a deployment mode incorporates the count into the pre-release number and clears `BuildMetaData`. On a selected tag at HEAD, both source SHAs are HEAD and distance is zero. `Sha` and `ShortSha` always identify the current commit.
99
+
100
+
See [calculation strategies](/docs/reference/version-sources) for selection and counting rules. Missing source values are JSON null in the new fields; textual outputs such as environment variables and MSBuild properties use empty strings.
101
+
84
102
## Formatting Variables
85
103
86
104
GitVersion variables can be formatted using C# format strings. See [Format Strings](/docs/reference/custom-formatting) for details.
Copy file name to clipboardExpand all lines: docs/input/docs/reference/version-sources.md
+13-1Lines changed: 13 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -20,12 +20,24 @@ Strategies are selected with the [`strategies` configuration setting](/docs/refe
20
20
21
21
## Selection and increments
22
22
23
-
The order of entries in `strategies` is not a priority list. GitVersion evaluates candidates and selects a next version with a corresponding version source. Fallback is deferred until other strategies have been considered.
23
+
The order of entries in `strategies` is not a priority list. GitVersion evaluates candidates and selects a next version, preserving its semantic source separately from the commit-count anchor. Fallback is deferred until other strategies have been considered.
24
24
25
25
Do not interpret a source as “always increments” or “never increments” without the relevant branch configuration. Tagged commits, merge handling, increment inheritance, and deployment mode affect the outcome.
26
26
27
27
For the sequence of operations, see [how versions are calculated](/docs/learn/how-it-works).
28
28
29
+
## Semantic source and commit-count source
30
+
31
+
The **semantic source** supplies the baseline version and its final increment. Tags and merge messages have associated commits. Configuration values and branch names are external sources: they do not intrinsically belong to a commit. Mainline can fold several operations into a derived baseline while retaining its source provenance. The source is not a detector for every commit that contains a version-bump message.
32
+
33
+
The **commit-count source** anchors the count of commits reachable from the current commit, excluding commits reachable from the anchor and applying the configured ignore filters. This is a graph count, not first-parent distance or a count of builds. A null anchor counts all reachable, non-ignored history.
34
+
35
+
GitVersion compares candidates by their incremented semantic version. For multiple equal candidates with source commits, it selects the latest source timestamp. Otherwise the counting search prefers a commit-backed candidate by descending incremented version and then source timestamp. When the winning version is stable, pre-release base candidates are excluded from this counting search. Only when no commit-backed candidate remains does it use a null anchor. The order in `strategies` does not establish precedence.
36
+
37
+
For example, a `1.0.0` tag can remain the counting anchor while configuration or the branch name `release/5.0.0` supplies a `5.0.0` baseline. Replacing that anchor with the external semantic source would reset the meaning of the count. A later tag that raises the numeric version is reflected in semantic provenance without changing the selected counting anchor.
38
+
39
+
See the `SemVerSource*` and `CommitCountSource*`[output variables](/docs/reference/variables). The legacy `VersionSource*` fields retain their existing values for compatibility; they mix the two concepts.
40
+
29
41
## Existing source topics
30
42
31
43
The following anchors are retained for older links.
Copy file name to clipboardExpand all lines: src/GitVersion.Core.Tests/VersionCalculation/Approved/VariableProviderTests.ProvidesVariablesInContinuousDeliveryModeForFeatureBranch.approved.txt
Copy file name to clipboardExpand all lines: src/GitVersion.Core.Tests/VersionCalculation/Approved/VariableProviderTests.ProvidesVariablesInContinuousDeliveryModeForFeatureBranchWithCustomAssemblyInfoFormat.approved.txt
Copy file name to clipboardExpand all lines: src/GitVersion.Core.Tests/VersionCalculation/Approved/VariableProviderTests.ProvidesVariablesInContinuousDeliveryModeForPreRelease.approved.txt
0 commit comments