`autobump` doesn't aggregate version changes from commit messages

[GrayCatCode]

This is probably not an issue, but I thought I'd log it as one just to be sure:

I've implemented the autobump custom commit message scheme as you described the original example in the documentation; i.e.:

autobump { majorPattern = ~/(?m)^[bump-major]$/ # match "[bump-major]" on its own line without leading or trailing characters minorPattern = ~/(?m)^[bump-minor]$/ # match "[bump-minor]" on its own line without leading or trailing characters patchPattern = ~/(?m)^[bump-patch]$/ # match "[bump-patch]" on its own line without leading or trailing characters newPreReleasePattern = ~/(?m)^[make-new-pre-release]$/ # match "[make-new-pre-release]" on its own line without leading or trailing characters promoteToReleasePattern = ~/(?m)^[promote-to-release]$/ # match "[promote-to-release]" on its own line without leading or trailing characters }

I updated the semantic-build-versioning.gradle file with the above configuration and checked it in with [bump-minor] in the commit message on a separate line. At that point in the repo, the last tag was 0.2.0 which was some commits previous, and all branches and pointers were up-to-date on the latest commit. When I did a clean build the build broke given the # characters aren't recognized as comments in Groovy (doh!) so I had to replace them with the appropriate // characters. Once I did that all was well, and sure enough a clean build gave me a version of 0.3.0 as expected.

I then had to check in the updated version of the semantic-build-versioning.gradle file with the appropriate comment changes, and I used the [bump-patch] string in the comment (on a separate line of course, no leading/trailing spaces). When I did a clean build I expected a version of 0.3.1, but got 0.3.0 instead. Now I realize that the minor bump has higher precedence than the patch bump, but I would have expected that both (all) bump comment strings would have been aggregated since the last tag and would have moved the version accordingly. Is that not how it's supposed to work?

Many thanks again for your time and patience! :)

[GrayCatCode]

To clarify, I would expect the autobump to work as follows, given my particular case:

Tag	Commit Msg	Version
	[bump-patch]	0.41
	[bump-minor}	0.4.0
	[bump-patch]	0.3.2
	[bump-patch]	0.3.1
	[bump-minor[	0.3.0
0.2.0

The two patch bumps after the first minor bump would be rendered OBE by the second minor bump, then the next patch bump would increment that placeholder again, etc. Thank you again!

[vivin]

@Andrew-Poloni This behavior is a significant source of confusion :) I will try and add some documentation around it.

The aggregate behavior is based on precedence and the end result is always calculated with respect to an existing tag.

For the behavior you describe, there would need to be a tag (and corresponding release, I would imagine) for each commit with a version-bump message, which I also imagine, is not the intended behavior.

Also, if we did calculate the end tag based on the aggregate behavior the way you describe, it would cause version series to be skipped. You could go from 0.2.0 to 0.4.1, but what happened to the 0.3.x series?

[GrayCatCode]

This behavior is a significant source of confusion :) I will try and add some documentation around it.

LOL, thank you! I'm new to using the plugin so I'm still trying to figure out its behavior and how it's best employed. I appreciate your insight and patience as always! :)