Change default increment strategy for release branches to None instead of Patch

[GeertvanHorrik]

Fixes #1897

[bording]

I have to say that I really don't like that this change was made in a patch release, because this is a breaking behavior change.

Our branching model relied on the the default being Patch, so now instead of just being able to update the package, we have to modify all of our GitVersion.yml files as well.

[GeertvanHorrik]

@bording I am really sorry this has bitten you. It was never the intention to break behavior for anyone. The reason I fixed this was because it was bumping the patch on every commit (while still in the hotfix branch, so not a completed hotfix). In the past, the behavior has always been to increase the patch once a hotfix has been completed, so I thought I was fixing a quite critical bug.

Imagine a hotfix taking 10 commits, that would mean an instant bump of the patch to 10. Is there a specific reason you choose this strategy over just doing 1 patch increase per hotfix?

Again, sorry for the inconvenience caused by this.

[bording]

Is there a specific reason you choose this strategy over just doing 1 patch increase per hotfix?

Earlier this year, we switched to Release Flow, where we have a master branch and long-lived release-x.y branches. These release branches are where all tagging happens, and we ship from those branches.

I set this up with the following GitVersion.yml settings:

assembly-versioning-scheme: Major
next-version: 1.0
branches:
  master:
    mode: ContinuousDeployment
    tag: alpha
    increment: Minor
    tracks-release-branches: true
  release:
    tag: ''

This means that when we tag a release on a release branch, we want the next commit past that tag to start building the next patch release.

By changing the default on release branches from Path to None, this is broken.