+semver: major bumps minor, should bump major change

[MiroKov]

Adding +semver: breaking or +semver: major will cause the major version to be increased, +semver: feature or +semver: minor will bump minor and +semver: patch or +semver: fix will bump the patch.

We use GitVersion 4.0 nuget package.
When we add message +semver: major, it causes a minor change. Should cause a major change.

[MiroKov]

Any news on this? This behaviour is also on

GitVersionTask version 4.0.1-beta1-50

Expected behaviour: +semver: breaking or +semver: major -> causes major bump.

Actual behaviour: +semver: breaking or +semver: major -> causes minor bump.

Use case:
We use this GitVersionTask to version our master branch.
Without semver messages in commits -> patch is bumped.
We use the default settings, no yml files.

[waaromikniet]

We are having the same issue

[pietergheysens]

Same issue here on my side while building in Azure DevOps using GitVersion 4.0.3. Adding +semver:major in commit message only increments the minor version. The strange thing is that it only does not work when the last tag is set to 0.x.y. Once a tag is set to 1.x.y it seems to work as expected.

NOT OK => tag in master is set to 0.1.0

• new feature branch with extra commit message +semver:major results in 0.2.0

[prokhorovn]

Also facing the same problem
+ additional information

Seems like minor will be bumped instead of major only when current major = 0 (same described by @pietergheysens)
For example:

1. Current head in master is 0.1.0
2. Merge changes containing bumpmessage +semver: major
3. Result master version is 0.2.0 (1.0.0 expected)
   Example2:
4. Current head in master is 1.0.0 (added label to head commit)
5. Merge changes containing bumpmessage +semver: major
6. Result master version is 2.0.0 (2.0.0 expected) !

Conclusion: seems like bug reproduces only when major number = 0

[FixRM]

Same problem, any fixes? I use yaml configuration to override semver regex:

mode: ContinuousDelivery
major-version-bump-message: '(breaking|major):'
minor-version-bump-message: '(feature|minor):'
patch-version-bump-message: '(fix|patch):'
no-bump-message: '(none|skip):'
ignore:
  sha: []

'breaking' updates minor version

[martinhoza]

Same here. This way we have to start every new project with the version 1.0.0, which can be confusing. Or set 1.0.0 for the first time manually.
EDIT:
Actually, if you think about it - AND I AM NOT A PROFESSIONAL WHEN IT COMES TO VERSIONING, BUT ... - as long as you have a 0-Major version, your software is not yet released. In this time a lot of changes make a breaking change, but still at the end you reach version 1.0.0. Because from 0.0.0 (nothing) to anything productive it is an implicit breaking change. So GitVersion not bumping the major version too soon might not be such a drama after all. As soon as you think, you are somewhat near to go into production, you just manually set the tag on your develop branch to v1.0.0-alpha.0 or whatever you like. This might not apply for all scenarios, but I guess I can live with that.

[jim-paton]

I've just lost a couple of hours because of this issue. The problem appears to be here:

GitVersion/src/GitVersionCore/IncrementStrategyFinder.cs

Lines 37 to 41 in 9e5d482

	// cap the commit message severity to minor for alpha versions
	if (baseVersion.SemanticVersion < new SemanticVersion(1) && commitMessageIncrement > VersionField.Minor)
	{
	commitMessageIncrement = VersionField.Minor;
	}

I have no problem with this restriction apart from the fact that I can't find any reference to it in the documentation. If it's intentional, then the fact that the commit message can't be used to increment from 0.x.y to 1.0.0 needs to be clearly stated in the documentation.

Edit: Happy to submit a PR if given an indication as to whether it's the code or the docs that should be changed.

[jim-paton]

Actually, I think this restriction should be removed. I tried to work around it by tagging my branch with v1.0.0 before it got merged - however that then resulted in a version of 1.0.1 when picked up by our build system, so I've actually ended up with a skipped version.

[martinhoza]

true and ... also true... since there already is a special treatment of the pre-release / baby phase of a project with versions <1.0.0, but it is quite trivial and not satisfying at all, I'd suggest either removing the logic completely like @jim-paton suggested. OR adding some control of it, e.g. some additional magic words for a commit message saying "yes, we are almost there, but need to tweek the last few things and would like to have the version 1.0.0-alpha.0 now".
Or?

[gep13]

@jim-paton @martinhoza what happens if you try setting the following:

https://github.com/cake-contrib/Cake.Recipe/blob/develop/GitVersion.yml#L1

to 1.0.0

[martinhoza]

Genius. Is still ugly. It seems, next-version can really only bump the version higher. So the setting 1.0.0 only bumps to 1.0.0, while there is no tag "v1.0.0". Once there is some tagged version >= 1.0.0 the "next-version" setting seems to be ignored, e.g. it only applies if it is higher than the last version tag. Which makes the name "next-version" a little confusing. But yes, seems to be another way to go.

[jim-paton]

I'd suggest at a minimum that some /diag output is required inside that logic to indicate that it's bypassing the "normal" operation. It would save someone else encountering the same issue and having to clone the repo and debug just to find out why it's not working the way the docs say it should.

[gep13]

@martinhoza said...
Once there is some tagged version >= 1.0.0 the "next-version" setting seems to be ignored

Yes, that is exactly right, and how it is expected to work. At least in my head.

Where I used it in my example was that I have already released 1.0.1 and then 1.1.0 of the application, but now I want to start pushing out alpha's of 2.0.0 because I know that I have breaking changes coming up. As a result, I set the next-version to be 2.0.0.

[martinhoza]

Another suggestion: Add two lines to the documentation about how to move from 0.x.x to 1.x.x and why that is treated special. And another 1 line about how next-version really works - explained for dummies, so I would understand.

Yes, knowing how next-version really works is helpful - instead of faking some version tags just set next-version and from that on everything still works as expected.