Add version bumping strategy 'commit message'

[JakeGinnivan]

I would like to bump the major or minor by having certain keywords in my commit message..

It would be done via two configuration properties, both accepting a RegEx value with the keys and their default values being:

major-version-bump-message: (\+semver:.?breaking|breaking:)
minor-version-bump-message: (\+semver:.?(feature|minor)|(feature|minor):)

The match should be case insensitive.

This will match Api change doing blah +semver: breaking and breaking: Api change doing blah
And minor can be new feature description +semver: feature or feature: new feature description

[andreasohlund]

I like both, regarding the second how about adding a gv: or gitversion: just to make sure we don't bump by mistake. eg.

+gv:major or +gitversion:major

[pvandervelde]

I'd vote for using +gv:breaking and +gv:feature (maybe also allow using +gitversion:XXXX). I'd prefer these over using +gv:major and +gv:minor because using breaking and feature (or another term for feature) more clearly indicate what happened in that specific commit (i.e. there was a breaking change as indicated by the breaking attribute).

One thing to think about though would be the difference in applying a breaking change to the version for version numbers below 1.0, because in that case I'd expect a breaking change to also bump the minor version and not the major version. Mainly because the change from pre-1.0 to 1.0 is a decision that is hard to make automatically.

[andreasohlund]

I like the +gv: breaking , pretty similar to: https://github.com/boennemann/semantic-release#how-does-this-work

That said since we're actually talking about a semver breaking change should we consider: semver: breaking change to be less gitversion specific?

[pvandervelde]

+1 for the +semver:breaking option. Maybe the other option should then also be +semver:feature?

[JakeGinnivan]

Why not make this configurable.

major-version-bump-message: <regex>

:)

[andreasohlund]

Yea, +semver: feature sounds good.

Why not make this configurable.

at least as the default option :)

[JakeGinnivan]

So what about

major-version-bump-message: (\+semver:.?breaking|breaking:)
minor-version-bump-message: (\+semver:.?(feature|minor)|(feature|minor):)

This will match Api change doing blah +semver: breaking and breaking: Api change doing blah

And minor can be new feature description +semver: feature or feature: new feature description

[andreasohlund]

+1

On 16 Feb 2015, at 20:54, Jake Ginnivan [email protected] wrote:

So what about

major-version-bump-message: +semver: breaking
minor-version-bump-message: +semver:(feature|minor)
—
Reply to this email directly or view it on GitHub.

[JakeGinnivan]

Updated issue description. It is up for grabs so anyone can grab it :)

[robdmoore]

Great idea!

On 17 Feb 2015, at 4:36 am, Jake Ginnivan [email protected] wrote:

Updated issue description. It is up for grabs so anyone can grab it :)

—
Reply to this email directly or view it on GitHub.

[roryprimrose]

Are there any special rules around using this? I've tried an empty commit against develop (local), a commit with a change to the readme.md in a feature branch (also local) and I still see the existing versioning scheme. I've tried with commit messages of

+semver: minor

and then tried

Version bump to 2.4
+semver: minor

Still no joy. Are there special conditions that cause this comment to be actioned?

My GitVersion.yml is

mode: ContinuousDeployment
branches: {}
ignore:
  sha: []

I've also tried making the following change to the GitVersion.yml (on disk change only, no commit) but it still builds a 2.3.0 release.

next-version: 2.4.0
mode: ContinuousDeployment
branches: {}
ignore:
  sha: []
commit-message-incrementing: Enabled

[roryprimrose]

Hmmm, I think this is my lack of understanding. I'm trying to bump minor on a develop branch after I have created a release-2.3 branch which is going through a release candidate phase.

The last known version source on the develop branch was a v2.2.9 tag. The develop builds were correctly building 2.3.0 builds based on the 2.2.9 tag. I had assumed that adding a commit message to bump minor would have taken 2.3.0 to 2.4.0. I guess it doesn't because it is bumping from the 2.2.9 tag and coming up with the 2.3.0 version again.

I can't tag 2.3.0 anywhere because it hasn't been finalised in the release-2.3 branch. I am assuming that my only option is to put a next-version: 2.4.0 into the GitVersion.yml in the develop branch to get the desired result.