fix: do not use tags for normal prerelease dependency bump

[hanseltime]

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:

1. still consider tags if an explicit options flag is set
2. Only consider lastRelease if not. (Which is the only way that it is used currently).

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.

• New code is covered by tests
• All the changes are mentioned in docs (readme.md) - There are no external changes

[antongolub]

@hanseltime,

Thanks for the digging. I'm worried about default behavior changing. Maybe it's better to introduce skipTagsFetch instead?

[hanseltime]

@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.

[hanseltime]

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 🤞

[juancarlosjr97]

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 #98

[hanseltime]

This ended up being set up in different PR due to the large changes needed.

#97