|
1 | 1 | # Versioning modes
|
2 |
| -GitVersion has multiple modes to fit different |
| 2 | +GitVersion has multiple modes to fit different different ways of working. |
| 3 | + |
| 4 | + |
| 5 | +## Continuous Delivery |
| 6 | +This is the default mode, GitVersion calculates the next version and will use that until that is released. For instance: |
| 7 | + |
| 8 | + - 1.1.0+5 |
| 9 | + - 1.1.0+6 |
| 10 | + - 1.1.0+7 <-- This is the artifact we release, tag the commit which created this version |
| 11 | + - 1.1.1+0 |
| 12 | + |
| 13 | +Tags are required in this mode to communicate when the release is done as it's an external manual process. |
| 14 | + |
| 15 | +## Continuous deployment |
| 16 | +Sometimes you just want the version to keep changing and continuously deploy. A good case for this is when using Octopus deploy, as you cannot publish the same version of a package into the same feed. |
| 17 | + |
| 18 | +For this mode we followed the logic in this blog post by Xavier Decoster on the issues of incrementing automatically - http://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions |
| 19 | + |
| 20 | +As such we force a pre-release tag on all branches, this is fine for applications but can cause problems for libraries. As such this mode may or may not work for you, which leads us into a new mode in v4. Mainline development. |
| 21 | + |
| 22 | +## Mainline development |
| 23 | +Mainline development works more like the Continuous Delivery mode, except that it tells GitVersion to *infer* releases from from event. |
| 24 | + |
| 25 | +This mode is great if you do not want to tag each release because you simply deploy every commit to master. The behaviour of this mode is as follows: |
| 26 | + |
| 27 | +1. Calclate a base version (likely a tag in this mode) |
| 28 | +1. Walk all commits from the base version commit |
| 29 | +1. When a merge commit is found: |
| 30 | + - Calculate increments for each direct commit on master |
| 31 | + - Calculate the increment for the branch |
| 32 | +1. Calculate increments for each remaining direct commit |
| 33 | +1. For feature branches then calculate increment for the commits so far on your feature branch. |
| 34 | + |
| 35 | +Here is an example of what mainline development looks like: |
| 36 | + |
| 37 | + |
| 38 | + |
| 39 | + |
| 40 | +**WARNING:** This approach can slow down over time, we recommend to tag intermitently (maybe for minor or major releases) because then GitVersion will start the version calculation from that point. Much like a snapshot in an event sourced system. We will probably add in warnings to tag when things are slowing down. |
0 commit comments