Closed hanseltime closed 10 months ago
@hanseltime,
Thanks for the digging. I'm worried about default behavior changing. Maybe it's better to introduce skipTagsFetch
instead?
@antongolub -
Sure thing. I'll update with a flag in the near future. I forgot that there may be people who have altered their workflows to circumvent this already. Will comment when I have updated it.
Just wanted to post here. In order for the refactor to work, I need to make a few tests, but since my mac updated all of the temporary git tests are breaking. I will be looking into it.
I will try to have it up within a week 🤞
I am not 100%, but would this also address indirectly the conflict of semantic release and multi-semantic-release are using the same note to check if a released can be executed or not?
See https://github.com/qiwi/multi-semantic-release/issues/98
This ended up being set up in different PR due to the large changes needed.
Fixes Issue 75
On Extensive debugging, the prerelease "next" logic that we use for bumping dependencies is disregarding the "_lastRelease" on a package and biasing on the git tags. This is an issue though, because we always end up having run the previous package's release thanks to the topo library, so there is a tag indicating the current release. Our desired release is this tag though and not the next increment. It is, however, the desired bump of the "_lastRelease" of that package.
Changes
To fix this, we keep a light touch by augmenting getNextPreVersion to:
Since this is only actually used by the prerelease version and it is a well documented bug, the behavior of looking at tags is removed completely since _lastRelease should always be called by preceding packages and if not, would be handled by a failure in the preceding analyzeCommits.