Prefer -Dchangelist.format=%d.v%s

[jglick]

Judging by jenkinsci/lib-version-number@0071313 this should work better to support backport branches.

[daniel-beck]

The test is a bit short. I like where this is going based on the description, but it doesn't express enough what the result it accomplishes is.

One minor gripe is that for me, v followed by a letter is not quickly identifiable as a prefix, but I guess there are few alternative options that don't look even weirder.

[jglick]

Basically I need to ensure that there is some prefix you can add to version before ${changelist} for a backport branch which

• is recognizably derived from at least the main (numeric) portion of the version of the branch point
• ensures that backport versions sort after the branch point but before the next trunk version
• ensures that backport versions sort numerically

With the %d.%s format I could not find a good option that worked reliably: the truncated commit hash was too liable to be misinterpreted as an integer with some trailing garbage. With this amendment you can just use 123. where the branch point was 123.v************: 123.v************ < 123.1.v************ < 123.2.v************ < 124.v************

[daniel-beck]

Thanks for taking care of this!

[jglick]

To test, I am deliberately being a temporary jerk and merging jenkinsci/file-parameters-plugin#27 before jenkinsci/file-parameters-plugin#31, but then relenting and cutting a 99.x branch with a backport of the bug fix.

[jglick]

jenkins-infra/github-reusable-workflows#14 may be an issue, unclear.

[jglick]

So now the 2.263.x UC serves https://github.com/jenkinsci/file-parameters-plugin/releases/tag/99.102.vbc6a133bcbbb while the 2.281 UC serves https://github.com/jenkinsci/file-parameters-plugin/releases/tag/110.vbe06c86f5235, as expected.

[jtnord]

this seems incorrect or at least incorrectly applied in plugins where they are just using this and not prefixed version (e.g. mailer) - Maven treats 123.vxxxx as a String. and the entire major version will be empty.

This leads to people using versions like 391.ve4a_38c1b_cf4b_ which is older (in Maven) than 1.1

Whilst Jenkins (hudson.util.VersionNumber) is fine with this - Maven and all its related tooling is not.
This will break for example things that use maven version comparison, for example dependabot, maven-versions-plugin etc..

def cdVerJ = new hudson.util.VersionNumber("391.ve4a_38c1b_cf4b_")
def oldVerJ = new hudson.util.VersionNumber("1.1")

println("is Jenkins CD older " + cdVerJ.isOlderThan(oldVerJ))


def cdVerM = new org.apache.maven.artifact.versioning.DefaultArtifactVersion("391.ve4a_38c1b_cf4b_")
def oldVerM = new org.apache.maven.artifact.versioning.DefaultArtifactVersion("1.1")


println("cd version major maven" + cdVerM.getMajorVersion())
println("cd version major maven " + oldVerM.getMajorVersion())

prints (in the Jenkins console)

is Jenkins CD older false
cd version major maven 0
old version major maven 1

it would seem to me like the changelist format should be %d-v%s to work in all cases where a revision is specified or not.

[jglick]

More likely just seeing #24?

[daniel-beck]

More likely just seeing #24?

@jglick The sample code in the previous comment demonstrates the problem with a version number with a_ and b_ though.

[jtnord]

nope
sorry for the noise - I ran the check inside Jenkins in the script console. When I use Maven libraries directly from maven 3 (3.8.4) maven does sort the version as newer, older versions of maven (2.x) sort as originally described.

Jenkins is exposing the mave2 version of the library.

There is no reason to be using maven 2 so I guess this should be closed.
The Major version is parsed as 0 in both cases, but a version comparison (compareTo) with maven3 libs works correctly.

[jglick]

Not noise! Maven handling of version numbers is complex and prone to odd behaviors (as we saw in #24) so we need to remain on the lookout for subtle problems affecting JEP-229.