New changelist format in git-changelist-maven-extension 1.3 breaks RevApi

[uhafner]

Jenkins and plugins versions report

Environment

Paste the output here

What Operating System are you using (both controller, and any agents involved in the problem)?

https://ci.jenkins.io

Reproduction steps

See below.

Expected Results

See below.

Actual Results

See below.

Anything else?

The new version format introduced in git-changelist-maven-extension 1.3 breaks the version scanner of RevApi when used in Jenkins CI builds.

Example pull request:
jenkinsci/analysis-model#751

Produces the following error:

12:18:56  [INFO] Comparing [edu.hm.hafner:analysis-model:jar:10.9.0] against [edu.hm.hafner:analysis-model:jar:10.10.0-rc4532.e23f4fcb_78e4] (including their transitive dependencies).
12:18:57  [INFO] ------------------------------------------------------------------------
12:18:57  [INFO] BUILD FAILURE
12:18:57  [INFO] ------------------------------------------------------------------------
12:18:57  [INFO] Total time:  04:09 min
12:18:57  [INFO] Finished at: 2022-01-06T11:18:57Z
12:18:57  [INFO] ------------------------------------------------------------------------
12:18:57  [ERROR] Failed to execute goal org.revapi:revapi-maven-plugin:0.14.6:check (run-revapi) on project analysis-model: Failed to execute the API analysis. Failed to analyze archives: Extension revapi.semver.ignore failed to initialize: Could not parse the version string '10.10.0-rc4532.e23f4fcb_78e4'. It does not follow the semver schema. -> [Help 1]

The full console log is available here:
https://ci.jenkins.io/job/Plugins/job/analysis-model/job/PR-751/1/console

While this can be fixed in RevApi I wonder if there is something I can do here in Jenkins to avoid that problem or if that needs to be fixed in RevApi?

[jglick]

I suppose it needs a fix in RevApi, whatever that is.

[uhafner]

Is there a reason that you are using underscores and not plus oder minus characters? Semantic versioning does not allow underscores (see https://semver.org):

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

I think that will be fixed in RevApi soon but other tools might have problems with these new versioning scheme as well.

[jglick]

Because JEP-229 does not pretend to follow SemVer at all? We produce a legal version according to Maven and jenkinsci/lib-version-number. Any tools which presume that the version format of Maven dependencies follows some third-party convention will need to be corrected or at least reconfigured.

[uhafner]

Isn't JEP-305 the actual thing that a lot of plugins are using right now? That JEP did work with semantic versioning quite well until this change. But hopefully, we get a fix for RevApi soon.

[jglick]

Isn't JEP-305 the actual thing that a lot of plugins are using right now?

“Incrementals”, yes. That will append -rcNNNN.XXXXXXXXXXXX to version numbers (and, as of #24, the XXX part may include _), but still presumes MRP and thus that the base version number is encoded in the POM and maintained by humans.

[jglick]

JEP-229 does not pretend to follow SemVer at all

And so as in revapi/revapi#263 (comment) if you are attempting to use a tool which normally requires SemVer you will have to make some changes: for example, by telling the tool to ignore version numbers altogether and simply report any incompatible changes. Alternately, jenkins-infra/jenkins-maven-cd-action#19