A bug edge case in gradle versioning for versions that end with a separator

[PhilipAbed]

Discussed in #33581

^{Originally posted by PhilipAbed January 12, 2025}

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

github

Please tell us more about your question or problem

The failed version is taken from here: https://mvnrepository.com/artifact/org.jenkins-ci.plugins/token-macro

input is: 400.v35420b_922dcb_

and it fails to tokenize this version in gradle.

to reproduce the bug
add a test to the lib/modules/versioning/gradle/index.spec.ts

it.each`
    input                        | expected
    ${'400.v35420b_922dcb'}     | ${true}
    ${'400.v35420b_922dcb_'}      | ${true}
  `('isVersion("$input") === $expected', ({ input, expected }) => {
    expect(api.isVersion(input)).toBe(expected);
  });

The first succeeds but the second fails because it ends with a _ separator

so i tried the same test in lib/modules/versioning/maven/index.spec.ts
and it works like a charm.

here's the results of Gradle versioning tokenize:

note: returns null when it reaches the last character _

here's the result of Maven versioning tokenize

I noticed both functions in gradle and maven have the same purpose but.

each of them consider different separators.

Gradle has "_" as a separator while maven considers it a normal letter.

They mention in gradle docs Versions are divided into parts using the characters [. - _ +].
yet they let you set a version that ends with a separator which is confusing our resolution

We should not deviate from the gradle docs.
but there's no harm in changing tokenize function to allow ending with a separator "_"