Increment semver based on feature/x or bugfix/x branch being merged

[tomqwpl]

I'm looking at gitversion and trying to understand how to best make use of it.
I can see that I can bump the semver in a number of ways, including using comments in commits.

It seems to me like using the fact that a feature/ or bugfix/ branch has been merged could also be a strategy?
That is, if "feature/xxx" is merged into develop, increment minor semver number. If "bugfix/xxx" is merged into develop, increment patch number.

I'd be interested to know whether that's a sensible idea or not as it would perhaps clarify whether my understanding of how it works is correct or not. On the face of it, gitversion seems simple, but the more I dig the more subtlety I find in terms of how to make effective use of it.

Thanks

[asbjornu]

Yes, using merge commits works. But I would recommend using git tag to cement the version number, which will also increase performance.

[tomqwpl]

Back to the original question here. The whole point of gitversion is that I don't have to work out the version numbers myself. So when I come to "release", I apply a git tag. What string do I tag with? I tag with "1.2.3" because the current version that gitversion is generating is "1.2.3+10" (say). The whole point of gitversion is that I don't figure out 1.2.3 myself, it comes from the information that is already in git.
The increase over the base version is determined by various strategies depending on configuration. I didn't like the strategy of "always increment minor" or "always increment patch". Using conventional commits or the "+semver:minor" comments at least allows you to have control over how things are bumped. But in most cases you don't even need that, since code goes in to the develop branch by merging feature or bugfix branches, so why not use that information, why do I then have to duplicate that by adding a comment to the merge commit with "+semver:minor" or "+semver:patch" appropriately?

[asbjornu]

The whole point of gitversion is that I don't have to work out the version numbers myself.

No, that is not "the whole point" of GitVersion. Some use it that way, but as git tag has benefits over just computing a version number, many use that to not having to rely on GitVersion to figure out answers to questions like "what commit corresponds to version 1.8.2?".

The whole point of gitversion is that I don't figure out 1.2.3 myself, it comes from the information that is already in git.

Not quite right. Yes, GitVersion will be able to compute the right version number in most cases and will provide guidance to which version number you may want to assign to a given commit. But if you decide that the changes warrant a different version number than what GitVersion computes, you're free to tag with 1.3.0 or 2.0.0 if you want to.

But in most cases you don't even need that, since code goes in to the develop branch by merging feature or bugfix branches, so why not use that information, why do I then have to duplicate that by adding a comment to the merge commit with "+semver:minor" or "+semver:patch" appropriately?

Branch names are ephemeral (branches are usually deleted after they are merged) and the commit message of a merge commit is not the same across all Git tools. There is some regex-based patterns coded into GitVersion that will detect merge messages from various popular tools, but I wouldn't base my entire versioning strategy on it.

[tomqwpl]

OK. well now I'm really confused what gitversion is for. If I'm choosing my versions and manually applying tags, what am I using gitversion for?

Look. Fine. We're clearly not on the same page here.

[HHobeck]

Actually it depends on your branching and merging strategy. Like @asbjornu says there are different motivation creating tags:

• If you create a release candidate and deploy it to a testing environment you will properly tag it as a preview-release
• If you release a version to Manufacturing on production you will properly tag it as a main-release
• If you want to alter the target version you will tag it and restart the ci/deployment pipeline
• If you want to boost performance
• If you just want to document it because of regulatory reason

You could automate this as well. As soon you are moving the package via ci or deployment pipeline you are going to create a tag with a script. Why do you think it is always a manually process?

If you don't want this neither then you don't need to. Therefore we have the mainline version mode which can be use without any tags: see Mainline Development

Also see this ticket here: increment: inherit from incoming branch #3114

Happy Branching!