Oliver Kuntze

Hey @RobWin , hope you're doing well. Do you have a ruff estimation for the release of 1.7.2 or fix of 1.7.1? Cheers Oliver

Same here

Unfortunately not. The plugin still infers the incorrect release version (0.0.1) but then checks this version against the latest semantic versioning tag. One part ist fixed, the other not. Seems...

Thanks for your reply, @DanielThomas ! I've tried 18.0.8 which still infers the incorrect dev version while 18.0.4 is working totally fine. Haven't tried out 19.x since it apparently changed...

Hi @DanielThomas . Unfortunately also 19.0.4 always infers for example 0.0.1-dev.something for the current dev version in our Gitlab CI pipeline. Even setting the git strategy to clone and shallow...

Our release tags are all prefixed with "v". The problem seems to be somehow associated with running the release tasks from within a Gitlab CI pipeline. I've tried git fetch...

Running the gradle tasks locally produces the following log messages: ` 2024-02-01T08:57:42.449+0100 [DEBUG] [nebula.plugin.release.git.semver.NearestVersionLocator] Nearest release: {version=1.4.78, distance=8}, nearest any: {version=1.4.78, distance=8}. 2024-02-01T08:57:42.449+0100 [DEBUG] [nebula.plugin.release.git.semver.SemVerStrategy] Located nearest version: nebula.plugin.release.git.semver.NearestVersion(1.4.78, 1.4.78,...

Oh damn. I think I found the cause of the problem. The "curated" executor image provided by our infrastructure team has git 1.8 on board which does not support the...

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

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