When develop increments with ContinuousDeployment mode?

[lexengineer]

Hello everyone 👋

Thank you for the answer in advance, my question might be kind of simple, but for me it is still not clear when my develop branch supposed to increment when the mode set to ContinuousDeployment

When I do commits it increments like that 0.1.0-alpha.69 => 0.1.0-alpha.70, but I already merged one release branch in the main branch, so main branch is 0.2.0 already and new release branch is 0.3.0-beta.1 as it supposed to be, anyway develop is keep using 0.1.0 and not incrementing the Minor version, unfortunately the documentation is very unclear about how it works and I do not want match, as I expected once I do a release and merge it down into master and develop, they both increment the version, master does that after the tag as mentioned inside the docs, but develop does nothing

[asbjornu]

Try adding a 1.0.0 tag and see whether develop starts incrementing appropriately then. GitVersion seems to have some trouble incrementing properly with version numbers below 1.0.0.

[lexengineer]

Thank you, that makes sense 👍

So just to make sure, the following flow should work, I have the following branches by following GitFlow:

1. develop
2. master
3. release-xxx - made from develop only
4. feature-xxx - made from develop only

Then I do the following, my initial version is 1.0.0 as you suggested, I create feature from develop, now my develop version is 1.0.0-alpha.1, do one commit and merge it back into develop with a PR, now my develop version is 1.0.0-alpha.2, now I create a release branch called release-1.2.0 from develop for example (does number inside branch name matters in that case? I assume not), my release version is 1.2.0-beta.1 now, then do one commit inside the release-1.2.0 and merge it back into master with a PR and tag my merge commit with v1.2.0, now my master version becomes 1.2.0, now I also merge my release-1.2.0 back into develop and at this point I expect my develop branch to become 1.3.0-alpha.1 because we already have 1.2.0 version for master and release-1.2.0 was merged.

Wondering if this sounds reasonable because I plan to do some testing and wondering if my expectations are correct, maybe develop should update it's version even without merging release into develop, but when we tag master?

[lexengineer]

Hello once again @asbjornu 👋

So I tried everything from scratch and found the following way how it probably works, looks like when I was merging release into master and back into develop with a separate PR-s, it was creating separate merge commits for each merge, so master <- release had merge-commit-A and develop <- release had merge-commit-B, after that I removed my release branch and develop version broke, the strange part is that when I was doing exactly the same not with PR-s, but with git merge --no-ff inside the terminal, everything was working as expected, so I am not sure what's wrong to be honest, any feedback is appreciated 😅

[asbjornu]

does number inside branch name matters in that case?

It matters for the version GitVersion generates for the release branch itself. But it does not matter for the target branch(es) the release is merged into.

after that I removed my release branch and develop version broke

What do you mean with "develop version broke"?

the strange part is that when I was doing exactly the same not with PR-s, but with git merge --no-ff inside the terminal, everything was working as expected, so I am not sure what's wrong to be honest, any feedback is appreciated 😅

GitVersion may behave differently on build servers depending on how stuff is configured. Also, take note of whether it is the merge-commit of the PR that is being built or HEAD of the PR. They will result in very different versions.

[HHobeck]

Thank you, that makes sense 👍

So just to make sure, the following flow should work, I have the following branches by following GitFlow:

1. develop
2. master
3. release-xxx - made from develop only
4. feature-xxx - made from develop only

Then I do the following, my initial version is 1.0.0 as you suggested, I create feature from develop, now my develop version is 1.0.0-alpha.1, do one commit and merge it back into develop with a PR, now my develop version is 1.0.0-alpha.2, now I create a release branch called release-1.2.0 from develop for example (does number inside branch name matters in that case? I assume not), my release version is 1.2.0-beta.1 now, then do one commit inside the release-1.2.0 and merge it back into master with a PR and tag my merge commit with v1.2.0, now my master version becomes 1.2.0, now I also merge my release-1.2.0 back into develop and at this point I expect my develop branch to become 1.3.0-alpha.1 because we already have 1.2.0 version for master and release-1.2.0 was merged.

Wondering if this sounds reasonable because I plan to do some testing and wondering if my expectations are correct, maybe develop should update it's version even without merging release into develop, but when we tag master?

What you are saying makes sense yes. ;) So as long you are following the GitFlow workflow it should be fine. Please take a look to the GitFlow examples diagrams. In my opinion it should be irrelevant if you merge from release/1.2.0 -> develop or from release/1.2.0 -> main -> develop. The source code on develop branch is in both cases the same and should generate the same version number. Yes it's important to tag the commit on the main branch.

[HHobeck]

Hi @oleksiikiselov. Is this question outdated or has been anwered already?