This issue, I think, is related if not the reason #72 was discovered.
It appears that the logic for determining versions, particularly in the context of !, is not working as intended when that ! commit is not the most recent.
In the screenshots below, the last tag was 3.0.0 so the expectation for these tests is that the version bump should be 4.0.0.
If commit 3fd23e8f5482f0ad0027a624ff6682492f45dc64 were the last commit, autotag would output 4.0.0 as intended.
It looks like in this loop the version bump is being set on each iteration, so long as as the bump is not nil. This will overwrite a major bump with a minor depending on the order of parsing. I believe this is what was causing the bug as well in #72, the order itself actually was not the issue. There just exists a possibility where a minor bump overwrites the major bump.
Possible Fix
I think in the loop above, just need to compare the current version to the previous version and somehow compare whether the current bump is greater than the previous and apply the biggest bump rather than applying the bump on non-nil (L392).
Can you also ensure that this fixes the ! mirror, IE BREAKING in the body?
This issue, I think, is related if not the reason #72 was discovered.
It appears that the logic for determining versions, particularly in the context of
!
, is not working as intended when that!
commit is not the most recent.In the screenshots below, the last tag was 3.0.0 so the expectation for these tests is that the version bump should be 4.0.0.
If commit
3fd23e8f5482f0ad0027a624ff6682492f45dc64
were the last commit, autotag would output 4.0.0 as intended.The Bug
https://github.com/pantheon-systems/autotag/blob/408aa18e6388b08364c6849456d54a0e577a854e/autotag.go#L381-L394
It looks like in this loop the version bump is being set on each iteration, so long as as the bump is not
nil
. This will overwrite a major bump with a minor depending on the order of parsing. I believe this is what was causing the bug as well in #72, the order itself actually was not the issue. There just exists a possibility where a minor bump overwrites the major bump.Possible Fix
I think in the loop above, just need to compare the current version to the previous version and somehow compare whether the current bump is greater than the previous and apply the biggest bump rather than applying the bump on
non-nil
(L392).Can you also ensure that this fixes the
!
mirror, IE BREAKING in the body?