Skip to content

Commit defc31b

Browse files
committed
Some initial docs on mainline mode and modes in general
1 parent 9a2cf14 commit defc31b

File tree

3 files changed

+40
-2
lines changed

3 files changed

+40
-2
lines changed

docs/configuration.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -24,7 +24,7 @@ The global configuration options are:
2424

2525
- **`assembly-informational-format:`** Set this to any of the available [variables](/more-info/variables) to change the value of the `AssemblyInformationalVersion` attribute. Default set to `{InformationalVersion}`. It also supports string interpolation (`{MajorMinorPatch}+{Branch}`)
2626

27-
- **`mode:`** Sets the mode of how GitVersion should create a new version. Can be set to either `ContinuousDelivery` or `ContinuousDeployment`. Read more about [ContinuousDelivery](/reference/continuous-delivery/) or [ContinuousDeployment](/reference/continuous-deployment/).
27+
- **`mode:`** Sets the mode of how GitVersion should create a new version. Read more at [versioning mode](./versioning-mode.md)
2828

2929
- **`continuous-delivery-fallback-tag:`** When using `mode: ContinuousDeployment`, the value specified will be used as the pre-release tag for branches which do not have one specified. Default set to `ci`.
3030

docs/img/mainline-mode.png

69.5 KB
Loading

docs/versioning-mode.md

Lines changed: 39 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,40 @@
11
# 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+
![Mainline mode](./img/mainline-mode.png)
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

Comments
 (0)