Since 18.0.4 NearestVersionLocator cannot handle non-semver tags (ie. "latest") correctly any more

[oliverkuntze]

Hey,

up until v18.0.3 the following scenario was handled correctly:

Given the following tag history of a repository in chronologically descending order:
latest
v2.0.0
v1.3.0
v1.2.4
Nebula release until v18.0.3 correctly detects v2.0.0 as the latest semver tag and infers the correct version calculates the correct next release version and tag.

Nebula release v18.0.4 however does not correctly detects v2.0.0 as the latest semver tag and infers instead version v0.0.1.
If there is a semver compliant tag chronologically newer than the tag "latest" nebula release v18.0.4 works as expected.

It would be great if you could revert the logic back to its prior v18.0.4 state.

Thanks a lot in advance!

Cheers

Oliver

[oliverkuntze]

@rpalcolea throwing an exception in parseTag when failOnInvalid is true and trying to parse "latest" seems to cause setting the current version to UNKNOWN meaning v0.0.0.
In our release step and a conventional commit of type fix this produces the v0.0.1 version I mentioned in my previous post.

I appreciate your effort and work regarding this great plugin. However the v18.0.0.4 patch version has introduced a breaking change meaning semver and non-semver compliant tags cannot be mixed in a repository any longer.

For all our services we use strict semver versioning excluding our ci repository since we don't want to wait for Renovate to "activate" the latest pipelines for our services. Hence in addition to semver tags we are are also using the "latest" tag for our ci repository.

[ryanlewis]

Also experiencing this issue. Reverted to 18.0.3 of plugin.

[oliverkuntze]

@rpalcolea , it would be great if you could provide us with some feedback. Is this new behaviour intended? If not, are you planning to fix it?
If we have two "nos", I could ask my PO for some capacity for me to fix this bug and provide a PR, if that is ok with you.
Any sign of life would be highly appreciated.

Cheers
Oliver

[pauxus]

Looking at the release notes: this should have been fixed with 7d369f6 (18.0.6)