Configurable next-version strategies and mode

[erikbra]

Running GitVersion, most of the time running, which can be quite long on large-ish codebases, is spent on looping through all version candidates on all versioning strategies on the codebase.

This includes traversing backwards using:

• FallbackBaseVersionStrategy
• ConfigNextVersionBaseVersionStrategy,
• TaggedCommitVersionStrategy
• MergeMessageBaseVersionStrategy
• VersionInBranchNameBaseVersionStrategy
• TrackReleaseBranchesVersionStrategy

Some of these are rather expensive. On our codebase at work, a lot of time is spent in MergeMessageBaseVersionStrategy. 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.

So, 1st suggestion is:

Making the strategies used configurable

2nd, I'd like to question if it is really necessary to loop through all previous commits in parents to find the "largest version" candidate. I am very open to being wrong here, but wouldn't the newest version found be the correct one to use for calculating the next version in 99% of all cases? At least, there could be a configurable setting to make it use the first/newest ancestor version on each strategy.

2nd suggestion is, then:

Make a config switch available to always use the newest version when calculating next

I'd be happy to take on this task, but I might need a little guidance on where I should put the new config values. Does it make sense to put them on the branch? Or globally?

I have attached a run of GitVersion of a codebase I am working on. In all strategies, it finds the correct version to use for calculating "next version" (2019.21.0) in the first try. First is after 3 secs. But it still loops through all commits in all strategies, and takes and additional 60secs (30 after my other #1838). I'd like it to stop after finding the first candidate for a strategy.

gitversion-diag.txt

[asbjornu]

I like your ideas. With "newest" version, are you thinking of not having to look at older commits once we've found a version number? How would we know whether potential branches involved in potential versioning strategies don't contain newer (or older) commits yielding a higher version number than the (first) one we've found?

Could you make an example of how the config value might look like so I get a better idea of what you're thinking of?

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

[asbjornu]

@erikbra, have you had any time to think about this? If so, could you please make a proposal for your suggested config switch?

[erikbra]

@asbjornu Sorry, I just haven't had any more time to look at this yet... don't want to suggest anything before having looked more at it... please, everyone, feel free to chip in ideas :)

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