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: README.md
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -46,9 +46,11 @@ If you have other branch types GitVersion is entirely configuration driven, so c
46
46
Those of you who have tried to do SemVer with Octopus Deploy or consume CI packages out of TeamCity would have hit
47
47
the problem that the SemVer version does not change each commit.
48
48
49
-
By default GitVersion is setup for *continuous delivery*, meaning that when you want to release you publish the artifact attached to your CI Build ([read more about what this means](https://github.com/ParticularLabs/GitVersion/wiki/Continuous-Delivery-Mode).
49
+
By default GitVersion is setup for *continuous delivery*, meaning that when you want to release you publish the artifact attached to
50
+
your CI Build ([read more about what this means](https://github.com/ParticularLabs/GitVersion/wiki/Continuous-Delivery-Mode)).
50
51
51
-
If you want to consume packages from you CI server, for instance Octopus Deploy is looking at TeamCity's NuGet feed then you want GitVersion's *continuous deployment mode*. See the [Configuration]
52
+
If you want to consume packages from you CI server, for instance Octopus Deploy is looking at TeamCity's NuGet feed then you want GitVersion's *continuous deployment mode*.
53
+
See the [Configuration](#configuration)
52
54
53
55
When using the continuous deployment mode all builds *must* have a pre-release tag, except for builds which are explicitly tagged as stable.
54
56
Then the build metadata (which is the commit count) is promoted to the pre-release tag. Applying those rules the above commit graph would produce:
@@ -66,6 +68,9 @@ b5d142 -> 2.0.0-ci.0 (2.0.0 branch was merged, so master is now at 2.0.0)
66
68
67
69
As you can see the versions now no longer conflict. When you want to create a stable `2.0.0` release you simply `git tag 2.0.0` then build the tag and it will produce a stable 2.0.0 package.
68
70
71
+
For more information/background on why we have come to this conclusion read [Xavier Decoster's blog post on the subject](http://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions).
72
+
The issue has also been discussed in quite a few issues. If you have other thoughts on this subject please open an issue to discuss!
73
+
69
74
### NuGet Compatibility
70
75
Again, if you have used NuGet you would notice the versions above are not compatible with NuGet. GitVersion solves this by providing *variables*.
0 commit comments