Pre-release tags on release branch

[devorient]

With the introduction of prevent-increment.when-current-commit-tagged and using the default configuration for workflow=GitFlow/v1, when building on a commit with a pre-release tag on a release branch, GitVersion increments the pre-release number (as the default configuration says it should).

I am somewhat puzzled on why this is the default behaviour.

Example:

* 783d08a8 (HEAD -> release/next, tag: v0.2.0-beta.1, origin/release/next)
* cd7ab297 (origin/develop, develop)

running GitVersion with default config on 783d08a8 produces v0.2.0-beta.2

[HHobeck]

In the case when branching from a tag on main I would expect a version increment. The algorithm just increments the version in case the prevent-increment.when-current-commit-tagged configuration is set to false independent whether the tag is a pre-release version or not.

Example:

* 783d08a8 (HEAD -> release/next, tag: v0.2.0, main, develop)

running GitVersion with default config on 783d08a8 produces 0.2.1-beta.0 not 0.2.0

Does this make sense?

[devorient]

I can see why it would make sense for this use case. Which, as I understand, is the logic for the introduction of this feature.

But then if I would tag the next commit with v0.2.1-beta.1 GitVersion would produce v0.2.1-beta.2 on that commit.
So if I am not mistaken, I would not be able to get GitVersion to produce v0.2.1-beta.1 in this case.

Am I misusing the pre-release tags? If not, shouldn't pre-release tags get another configuration parameter to address this?

[HHobeck]

Good question. It depends what your motivation is:

1. You want to build and deploy the (already released) version of the tag
2. You want to develop or bugfix the next version (not released)

I think the most user who are using the GitFlow/v1 workflow are motivated by the bulled point two. The process is normally you are:

• committing a change
• perform a build pipeline
• publish to a package manager
• deploy on a testing or production system
• tagging the pre-released or released version

You see in your scenario you have created a tag and want to deploy afterwards which differs from the process I have outlined. Why would you create a tag before deploying it? For me a tag is the documentation that is has been deployed and not can be deployed some time in future.

Anyway in some situation it might be necessary to create a version based on the tag. But then you would directly select the tag and not the branch.

I think we have a common deficit here. But hope you get the idea:

• [BUG]: GitVersion (in Azure Devops) calculating wrong version when building a tag #4015
• [ISSUE]: GitLab CI tag pipelines result in an incorrect version #4186
• Do not return the tag as branch name for GitLab CI #4187
• [ISSUE]: GitVersion crashes in GitHub Actions when an action is dispatched on a tag #4212

Is this something you can work with?

[devorient]

I see, then the default configuration makes sense to me in the context you pointed out. Thank you for taking the time to clarify it.

The flow I have been using is to tigger a release/candidate build when a tag is pushed to remote, which is the opposite of the flow you have described.
I have not tested the default behaviour on my release pipeline yet (bitbucket pipelines), so I'll investigate changing my way of working.

Are there any tasks you would suggest I pick up to help address the deficit you mention?

[HHobeck]

May I ask you if you don't want this behavior why you not just change the property prevent-increment.when-current-commit-tagged to true for the release branch?

[devorient]

I have done that and it resolved the issue I had mentioned in my original question. My intention with the question was to understand why incrementing was chosen as the default behavior.

When you pointed out the detached head issues, I realized that if I attempt to rebuild a pre-release tag, I would run into trouble still. Hence my interest in these discussions.
Your suggestion #4212 (comment) can solve this issue I believe.

[HHobeck]

When you pointed out the detached head issues, I realized that if I attempt to rebuild a pre-release tag, I would run into trouble still. Hence my interest in these discussions.
Your suggestion #4212 (comment) can solve this issue I believe.

Can you outline the scenario you have in mind?