sort according to VersionNumber comparator

[mawinter69]

The file plugin-versions.json is the base for sorting the releases of a plugin on the plugins page at https://plugins.jenkins.io
The sorting with string causes wrong ordering in some cases as described in jenkins-infra/plugin-site#1336

By sorting with the Comparator of VersionNumber we get the same sorting as in other places.

[daniel-beck]

Thanks.

Originally added in daniel-beck@64d85c2, but I don't remember why I added the TODO instead of simply addressing it. My best guess is that I wanted to have identical output with the large-scale overhaul of the tool, given the bad test coverage, so kept the existing behavior, just noting it for later. I guess "later" is now.

[zbynek]

This by itself won't be enough because plugin-site parses the JSON and sorts things independently (see e.g. https://github.com/jenkins-infra/plugin-site/pull/1297/files). Reusing ordering from update center would be great of coursem, but I'm not sure is a way to do that with the current JSON format. Unfortunatelly Object.keys in JS is mostly chronological, but with an exception for integers. And of course there is a plugin (gcr-scanner) where this would be a problem and version 1.0 would come after 2.

[daniel-beck]

plugin-installation-manager-tool is another consumer, but it doesn't look like it cares about order: https://github.com/jenkinsci/plugin-installation-manager-tool/blob/f131bc53adab6015f39229ae4c3eca937f2bb92f/plugin-management-library/src/main/java/io/jenkins/tools/pluginmanager/impl/PluginManager.java#L891-L892 (looks like it's only used when installing a non-latest version of a plugin, and having to resolve its dependencies).

[zbynek]

@daniel-beck please don't consider my comment blocking, I think this is an improvement, just needs a follow-up in plugin-site

[zbynek]

@daniel-beck is there anything blocking merge of this PR?

[daniel-beck]

@zbynek Nothing blocking this, except there was no real need for a new release AFAICT. Due to limited test coverage it's always a bit cumbersome to publish and use a new release, so I generally try to bundle up a bunch of changes. To make it easier to recover what those changes are (e.g. for the changelog) given the metadata is in the same repo and changes are far more numerous, I hold PRs until shortly before the intended release date.