Attempt to fix merge message issue

[david-driscoll]

This attempts to fix #1468, #1481.

This adds a new configuration value that effectively disables MergeMessageBaseVersionStrategy.

What I discovered in my testing is that if a merge message picks up a new version number, that will automatically become the latest the highest base version and then used in the next version calculation.

I feel like there could also be something added to the Merge Message strategy that looks at the branch configuration to determine the source branch, and ensure that it is a release branch (for gitflow).

[david-driscoll]

cc @gep13 @dazinator @JakeGinnivan 😄

[gep13]

@GitTools/developers what are your collective thoughts around this?

[asbjornu]

@gep13: As I think #1487 might have an effect on how this is solved, I'd like to merge that and possibly #1488 first. I'd also appreciate if @david-driscoll could have a look at those pull requests and give us his thoughts on them. If there's no objections, I'd like to merge #1487 in a couple of days, as @Kieranties has been waiting a while for that now.

[gep13]

@asbjornu I think that there might be some cross over between this PR and this one: #1507 as they both seem to be tackling a similar problem, but in a different way.

[konne]

@david-driscoll but I think to make the configuration more clear the commit-message should be move to the ignore.
like

ignore:
sha:

• xxxxxx
• yyyyyy
  messages: true

What do you think?

[asbjornu]

@gep13: Indeed. I hope @david-driscoll and @konne can agree on an approach so we end up with one PR we can merge. Either way, I'd like #1487 merged first. 🙂

[konne]

@gep13 I have no issue to make one PR out of that. I need only your okay, that you want it from the maintaner perspective. I also like to get this solved asap.

@david-driscoll What is your feedback?

[konne]

@david-driscoll please give your feedback

[david-driscoll]

Sorry didn't see the feedback earlier!

So I think both approaches add value, how they're configured and where they are configured is 🚲🏠 to me, so I don't really mind either way. As long as the blocker we're running into can be solved I'm happy. I'll defer to @konne's changes if he adds the additional filter for messages: false to the ignore settings in his PR, and we can close this one.

[konne]

@david-driscoll okay I will extend my PR. Please let your PR open until my is merged.

[gep13]

@david-driscoll are you in a position to take this PR for a spin to validate that this works as expected for you? Thanks!

[asbjornu]

Now that both #1487 and #1488 are merged, we should be good to merge this or #1507, but as I write in #1507 (comment), I'm missing some tests that verify the added feature. Since @konne has not replied, perhaps you would be up for writing those tests, @david-driscoll?

It might also be good to rethink the approach now that we have #1488 in place.

[asbjornu]

This PR is so out of date now that this has to be reworked from the bottom up, possibly in a completely new way due to #1487 and #1488. I'm therefore closing this PR, but please submit a new one if this is still something you'd like to see in GitVersion.