Can we be stricter with breaking change warnings

[ckipp01]

Hello! So, the warnings about breaking changes are incredibly useful. I love this feature. However, this last week I've noticed a few times where some combination of breaking change was used in the commit message where it's a really not a breaking change, but maybe talking about a breaking change. This sort of leads the user to take a closer look, look at the commit on github only to realize that the commit was like

The breaking change was introduced in blah and this pr fixes it.

For example I just had this today when I updated nvim-lspconfig and it brought it this commit: neovim/nvim-lspconfig@ac5d1d9. This one isn't a great example since the pr title gives it away, but as you know... some pr titles are pretty vague, so it forces you to go further.

This is tricky since if you get more strict on how exactly this is triggered, then you have commit messages that are getting pretty specific to packer, but if not, you end up with false positive like this. So this is more of just a discussion starter to see if there is any way we could tighten this up somehow to avoid the false positives without being super packer specific, Any ideas?

[wbthomason]

Thanks! I'm definitely open to suggestions for improving this - the current heuristic was arrived at from some discussion in the Neovim Gitter, but could definitely be improved upon. Getting the community to use a standard commit message format (which could e.g. include a tag for breaking changes) would be great, but is highly unlikely to ever happen.

We could maybe add an exclusion heuristic to complement the detection heuristic by filtering out patterns like "breaking change was introduced in <commit that isn't in the set included in the current update>", etc.?