… Here is my view on it and an example how it might be better. Not all unit tests are adapted right now from me. But this tests I have touched it looks quite good... That means the unit tests might be not correct implemented and false positive (or I have a fundamental different view on generating semantic versions). Hope this finds a way to a productive version of GitVersion because I put a lot of effort to this because I want to give something back. GitVersion is great and should be refactored more in direction of clean code. Thank you very much for given this a chance.

…l like I would expected it. But at one point I'm not certain. That's related how the version should be incremented when having a different VersioningMode ContinuousDelivery, ContinuousDeployment or Mainline. I think I have misinterpreted the parameter TrackMergeTarget and should be using instead the ContinuousDeployment value instead.

…et TrackMergeTarget to true for the main branch.

…et TrackMergeTarget to true for the support branch.

…et TrackMergeTarget to true for the develop branch.

…mmitsSinceVersionSourceShouldNotGoDownWhenMergingHotfixToDevelop test

…instances. In advance add a overload to specify the initial branch name for the empty repository. Last but not least the logic in BaseVersionCalculator has been adapted: If the maximal version has no pre-release tag defined than we want to determine just the latest previous base source which are not comming from pre-release tag.

… develop branch GitTools#3177

…rackMergeTarget functionality.

…sion strategy implementation is highly recursive and works with inheritance from one branch configuration to another. This makes it highly configurable and we can support every workflow on the world and all workflows which are created in the future. Please notice the BranchConfigurationCalculator is not really used anymore.

…merge to main

…Support

…hanges

…erface of IVersionStrategy to be able to pass in the effective configuration.

…ich are conceptional not the same. Create additional tests for EffectiveBranchConfigurationFinderTests. In advance the ContinuousDeploymentTestScenarios integration test class has been added.

…nch and ContinuousDeploymentTestScenarios.

…anch and the EffectiveConfiguration values. In advance this properties are now present in the NextVersion class to be prepaired to get rid of the Configuration property in the GitVersionContext class. No business logic has been changed in this commit.

…iness logic changed.

…and deleted this property. Therfore I need to pass the NextVersion class out of NextVersionCalculator. Normally the SemanticVersion should be enough. But magic happens in the VariableProvider so that's why the effective configuration of the calculated version is necessary as well. Just refactoring no business logic changed.

…test which was a duplicate.

…document the obsolete code. Remove unused method in RepositoryStore. No business logic changed.

…igurationFinderTests

…sts class.

…onStrategyTests and ConfigNextVersionBaseVersionStrategyTests.

…into feature/3101

…into feature/3101

… be inherited from parent.

…sMergedAndDeleted in NextVersionCalculator and move business logic to MergeMessageVersionStrategy class.

…tag will be present only on fallback branch configuration settings.

…into feature/3101

…nsions class.

Co-authored-by: Asbjørn Ulsberg <asbjorn@ulsberg.no>