Mainline: Increment non-master branches on same tagged commit?

[JustinGrote]

Using Gitversion 4.0.1-beta.1+2.Branch.master.Sha.0e77e2e16a136a1cd0f0474fe5710f617d508d81

Problem Description

Mainline works exactly as I'd expect except for when I tag a commit to a version.

For instance, I have master and develop. I make a commit to develop and merge it into master. Now both master and develop have the same HEAD at commit A.

If at this point I run gitversion on master, it'll say 0.1.1, and if I run it in develop, it'll say 0.2.0-alpha.0. This would be my expected behavior

If I tag master (Commit A) with v0.1.1 however, now if I run giversion on develop, it will now say 0.1.1 instead of 0.2.0-alpha.0. I suspect this is due to the versioning logic described of "if it sees a tag, stop processing" regardless of context.

The problem here is that if I do a pull request and merge develop, and Appveyor or someone tries to build "develop" natively, say for packaging and deployment, it will go out with the wrong version to that "prerelease" channel.

Recommended Fix

There should be an option in the .yaml file to flag non-master branches to say "if master has a tag, still process the mainline increment for gitversion based on this branch".

Suggested Name: increment-on-tag.

It could be placed in the branch context, or placed at the top to increment regardless of tags.

So if Commit A is tagged v0.1.1, and all branches have Commit A as their HEAD, I would expect to see in the gitversion output when switching to each branch:
Master: 0.1.1
Develop: 0.2.0-alpha.0 (because it defaults to Increment:Minor)
Hotfix: 0.1.2-hotfix.0 (because it defaults to Increment:Patch)

Known Workarounds

• Temporarily delete the tag, run gitversion, and then add it back (lame)
• Add an empty commit with "+semvver:skip" after every merge (lame, pollutes git history, and still increments the prerelease number unnecessarily leading to broken chains of versioning which is generally not allowed by SemVer)
• Always require net-new commits before builds in non-master branches (hard to enforce)
• Build the logic into the consumer of GitVersion that if the returned value is the same as a tag and the branch isn't master, then increment manually. (Lame, should be part of GitVersion obviously, that's its job.)

Thanks!

[dgrant]

I'm encountering this problem as well. Super annoying.

[JustinGrote]

I'm still doing the "delete and reapply tag after" method, only I'm now adding prerelease tags too because it hard fails using mainline mode if there's a prerelease tag. 6 months without response...

[derhally]

I ran into this today. I tagged master with version "1.2.0" then created a branch to work on a feature and the feature branch was being built as "1.2.0"

Will this issue be resolved by the fix for issue #1536 ?

[FuncLun]

This is a nagging issue for me as well. Even when building a commit tagged with a version, the version should be -{tag}.0, unless expressly configured for release build (i.e. in 'master' or via command line option).

For example, assume master is built using "Release" configuration and creates tag "1.2.3". Assume the build environment is automatically setup to build "Debug" builds for all feature/* branches. Branching from master to feature/widget will kick off a a "Debug" version as "1.2.3", potentially overwriting the existing "Release" version.

Recommended Fix

There should be an option to force prerelease version tagging. If set globally, even when master is built, the version will be #.#.#-ci.0.

Suggested Name: prerelease-tag: true|false.

It could be placed in the branch context, or placed at the top to increment regardless of tags. GitVersion.exe would have to be executed with an option to allow the release version to be generated. Leaving configuration set to false (default) would use current behavior.

prerelease-tag: false (current behavior)
(e.g. gitversion.exe /overrideconfig prerelease-tag=false)
AnyBranch: 0.1.1

prerelease-tag: true (new behavior)
Master: 0.1.1-ci.0
Develop: 0.2.0-alpha.0 (because it defaults to Increment:Minor)
Hotfix: 0.1.2-hotfix.0 (because it defaults to Increment:Patch)

Thank you

[asbjornu]

Is this fixed by #1540?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[thetimbecker]

I am running into this issue now as well. We open a release branch off of develop and would like that tagged as beta, but it just reused the alpha version.

Sometimes release branches don't need any additional commits, but we require a merge to master to come from a release branch.

[chriscone-nano]

@thetimbecker Did you find a work around for this? I would like to push the release branch that is cut off of the develop branch but does not have any additional commits. Creating a commit just to force this seems messy

[thetimbecker]

Sort of, our solution was to only tag commits to master. Then there aren't any tags on the commit so GitVersion uses the branch name to calculate version.

For us, master is the only place tagging is necessary, so this works for us. But it'd be great to have the option to add tags on all branches.

[asbjornu]

Only tagging on master sounds reasonable, although I agree that building another branch off the same commit should lead to a different version number. Are you certain GitVersion is picking up which branch is being built?

[thetimbecker]

Yes, I am certain. It is really easy to reproduce too, if you want to check for yourself:

$ git init
Initialized empty Git repository in /tmp/test/.git/

$ touch test
$ git add test
$ git commit -m "Initial Commit"
[master (root-commit) 0215112] Initial Commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test

$ gitversion /showvariable SemVer
0.1.0

$ git tag 1.0.0
$ gitversion /showvariable SemVer
1.0.0

$ git checkout -b feature/test-feature
Switched to a new branch 'feature/test-feature'

$ gitversion /showvariable SemVer
1.0.0

$ git tag -d 1.0.0
Deleted tag '1.0.0' (was 0215112)

$ gitversion /showvariable SemVer
0.1.0-test-feature.1