Replace the version mode Mainline in 6.x

[HHobeck]

I would like to discuss with you how to replace the version mode Mainline in 6.x. I have thought about it and did some prototyping ( see #3252 (reply in thread) and #3308 ).

I think we are agree on it that the VersioningMode.Mainline is not so nice and should be refactored. I would not say to remove the hole trunk-based workflow because I think there is a use case for it. My first thought was to just rename it from Mainline to Trunkbase but the logic of how the semantic version will be determined is completely different compared to the non-trunk-based workflows. Also in some situation when using the trunk-based workflow e.g. creating feature branches you would like to use continues-delivery or manually-deplyoment mode dependent on your deployment strategy. Thus the mainline alias trunkbased mode should not part of the version mode enum itself but it should be part of the versioning strategy implementation.

1. My idea is to just support VersioningMode with the values ManuallyDeployment (prev. ContinuesDelivery), ContinuesDelivery (prev. ContinuousDeployment) and ContinuousDeployment (new)
2. Remove the hole MainlineVersionCalculator implementation and consolidate it into TrunkBasedVersionStrategy (new)
3. Make the usage of used strategies configurable (with full qualified name and runtime assembly loading?)
4. Create base templates for GitHubFlow and GitFlow (NonTrunkBased) and Mainline (TrunkBased) workflow
5. The NonTrunkBased workflows are using the following strategy implementation: MergeMessageVersionStrategy, TaggedCommitVersionStrategy, TrackReleaseBranchesVersionStrategy, VersionInBranchNameVersionStrategy and ConfigNextVersionVersionStrategy
6. The TrunkBased workflow is using the following strategy implementation: TrunkBasedVersionStrategy and ConfigNextVersionVersionStrategy
7. All workflows are going to the same code base the only different is which strategies are used
8. Because it is part of the configuration everyone can create there custom strategy implementation or can inherit from existing one
9. With the initialization wizard we can ask which base templates (controled by the workflow property) should be used: GitHubFlow, GitFlow or TrunkBased
10. This comes the idea of removing the Mainline mode very close but with an option to keep it in an elegant way

[arturcic]

Make the usage of used strategies configurable (with full qualified name and runtime assembly loading?)

I would try to avoid loading assemblies, I think better to plan to take advantage on using .net 8 AOT in the 7.x version (that will require also the managed git to be implemented)

[HHobeck]

8. Because it is part of the configuration everyone can create there custom strategy implementation or can inherit from existing one

pays into the issue #1839 (Configurable next-version strategies and mode):

I don't think we need this, as we use tag-based versioning. We would benefit a lot being able to enable just the versioning strategy desired, alternatively a list of strategies. Not all strategies are applicable for everyone.

and issue #1419 (How to override version strategy computation):

Maybe would be a good idea to be able to disable commit stategies by configuration.

[HHobeck]

The final concept is to specify the following enums and replace VersioningMode with DeploymentMode. In addition a new property with name strategies (type VersioningStrategies[]) will be added on the configuration root level:

[Flags]
public enum VersioningStrategies
{
    None = 0,
    ConfigNextVersion = 1,
    MergeMessage = 2,
    TaggedCommit = 4,
    TrackReleaseBranches = 8,
    VersionInBranchName = 16,
    TrunkBased = 32
}

public enum DeploymentMode
{
    ManualDeployment,
    ContinuousDelivery,
    ContinuousDeployment
}

[HHobeck]

@arturcic @asbjornu please confirm. :)

[asbjornu]

👍🏼

[arturcic]

Yes, let's go with this implementation