Test Scenario for troubleshooting question/issue #2821

[anderson-dev]

Description

Unsuccessfully attempting to customize GitVersion to handle mainline versioning as shown in this sequence diagram
. I would prefer to use a "support" branch rather than the "hotfix" branch shown in the diagram. (It might be nice to have feature branches off the support branch but that causes even more version calculation discrepancies as they would still increment by minor as configured.)

If I set both feature & pull-request branch config to increment by minor, pull-requests seem to calculate as expected due to branch protection on master forcing pull-requests to be up-to-date. However, I'd like to be able to branch from an old tag to support an older revision via a support branch and then use a pull request to accept that fix into master (if the fix applies to future versions; otherwise I'll just tag it and leave it un-merged). In the defined test case, XenoLibPackages#CanCalculatePullRequestChanges, the second pull request for the support/hotfix branch increments by Minor rather than the support/hotfix branch that is configured to only increment by Patch level. It seems like pull-request version calculation should be based on the branch to be merged.

Related Issue

Issue #2821

Motivation and Context

Maybe it would be easier to have everything increment by patch by default but semver specifies that any new non-breaking feature should be Minor and any bug fix would be a Patch so I figured the vast majority of the time I'd be adding features in feature branches and bugfixes in hotfix/support branches. It would be nice if versioning would auto-calculate using this assumption and only require manual bumps when we expect a breaking change Major version.

My intention with this versioning strategy is to automate version calculation as much as possible, and minimize any developer involvement, for several small components that will be packaged for consumption by an encompassing project that will require a little more human intervention regarding releases. Mainline and minor version increments seems to get me there but Pull Request version should ALWAYS match the Major.Minor.Patch version of the branch to be merged (unless the pull-request is out of date with master) aside from pre-fix tag and build metadata in order for a beta package to be built and evaluated for the next expected version of the component.

How Has This Been Tested?

No code change; just unit test to validate my intended GitVersion config

Screenshots (if appropriate):

Checklist:

N/A this is just a throw away pull request to make things easier to troubleshoot issue #2821

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[asbjornu]

All tests beside dotnet format seems to pass. Shouldn't these tests fail due to GitVersion missing a feature they rely on?

[anderson-dev]

I'm not sure how your CI works and this is my first pull request I've ever created and this is a weird case because I'm not actually submitting anything for consideration as a new feature. I'm just trying to understand whether there is a disconnect with my intended configuration and the configuration I'm seeing.

However, if you select the 'Files Changed' tab, you can see my test case that I added and if you clone the code and run the test you will see that the test case fails at the end where it expects the pull request to be 2.1.1-PullRequestxxx.x but it is 2.2.0-PullRequestxxx.x

[anderson-dev]

If you drill down into the 'Details' link of 'CI / Unit Test code (windows-latest, net5.0) (pull_request)' check and then the 'Build' task and 'Unit Test' subtask, you will see where my unit test was run and failed but, for whatever reason, your CI system reports as though the unit test was successful

[asbjornu]

Can you explain this @arturcic?

[arturcic]

It should have failed the build. Interesting, need to check the branch locally

[arturcic]

@asbjornu I fixed the unit tests not failing in CI, @anderson-dev you can rebase on top of main

[anderson-dev]

pulled in your changes and it looks like the CI fails appropriately for my unit tests. Please take a look at them when able to determine whether there is a misunderstanding in my configuration in order to realize my intended strategy detailed above.

[anderson-dev]

Any thoughts on whether this is a feasible branch strategy?

[asbjornu]

With all of your feature and hotfix branches, are you really using Mainline, though? Mainline is created to support development flows such as GitHub Flow, where there is only a main branch and short-lived feature-branches that are usually squashed and forward-merged into main, without any merge-commits.

[anderson-dev]

Fair point. If there is another preferred strategy I'm open to it. Similar to your description, our master represents the current state of released code using very short-lived feature branches only to facilitate quality gate checks during pull request. This seems to match with GitHubFlow and I went with mainline because I want the master to auto-increment our released code in master rather than an additional step to promote for release considering our product is actually the aggregation of about 15 other repos that are auto-incremented.

I'd like normal development on feature branches to default to minor increments when PR is merged. If my devs are making a breaking change they've been instructed to bump the major. Though, I'd like to be able to use a hotfix or bugfix branch to represent a patch level increment. Though, this looks infeasible currently as once a pull request is submitted it bumps the minor instead.

[asbjornu]

I would advice you to try out mode: ContinuousDeployment instead and to use git tag <major>.<minor> every once in a while on main to adjust the version number accordingly.

[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.

[arturcic]

Closing in favor of #3445