Better support fo module version format

[alexeagle]

bazelbuild/bazel-central-registry#404 broke the registry.bazel.build site, because our deploy action has been broken: https://github.com/bazel-contrib/bcr-ui/actions/runs/4055858424

Error occurred prerendering page "/modules/rules_xcodeproj/1.0.0rc2". Read more: https://nextjs.org/docs/messages/prerender-error
Error: Invalid argument not valid semver ('1.0.0rc1' received)
    at validateAndParse (/home/runner/work/bcr-ui/bcr-ui/node_modules/.pnpm/compare-versions@4.1.3/node_modules/compare-versions/index.js:38:13)

I guess we have to patch this dependency to understand more semver formats, since rules_xcodeproj isn't following the spec https://semver.org/#semantic-versioning-specification-semver

/cc @brentleyjones

[alexeagle]

Alternatively we could tighten the semantics on BCR itself to reject versions that don't follow the semver spec.

[brentleyjones]

Ahh, dang. Yeah, it should have a -, sorry.

[brentleyjones]

https://bazel.build/rules/lib/bazel_module#version doesn't say it has to be semver btw (though I did intend for it to be semver). Also no mention of semver here: https://bazel.build/external/overview#bzlmod.

[hobofan]

According to this comment, the format is specifed in-code like this: https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/bzlmod/Version.java

That leads me to believe that there is no other place where this is formalized right now.

each segment in the "release" part can be identifiers instead of just numbers (so letters are also allowed -- although hyphens are not)

With that, 1.0.0rc1 should be valid and interpreted as release_segments: ['1', '0', '0rc1']

[brentleyjones]

When I release 1.0.0, will it be "newer" than 1.0.0rc1? If not, how can I fix this now?

[alexeagle]

I'd just run https://www.npmjs.com/package/semver-compare-cli via npx to answer that experimentally.

Do we think Bazel is correct here? Feels to me like we'll hit lots of other places where people's semver parsers will break and so BCR/bzlmod should be stricter about what it accepts.

[Wyverald]

The version format is specified here: https://bazel.build/external/module#version_format

"1.0.0rc1" is newer than "1.0.0" because "0rc1" > "0" per https://semver.org/#spec-item-11, sub-item 4

[brentleyjones]

Good to know. I think this might catch others as well. I'll work around my own mistake though.

[Wyverald]

https://bazel.build/rules/lib/bazel_module#version doesn't say it has to be semver btw (though I did intend for it to be semver).

This is quite an unfortunate situation :S https://bazel.build/rules/lib/bazel_module#version is the documentation for the bazel_module type (as in, the type of module_ctx.modules[0] in a module extension impl function).

The actual documentation for the module() directive is https://bazel.build/rules/lib/globals#module . The documentation organization is a flustercuck right now and I have a pending change to improve it, but I'm a bit afraid the potential for confusion will always be there.

[brentleyjones]

Just to confirm, 1.0.0.1 > 1.0.0rc1, right? (Actually, it's not, great)

[brentleyjones]

The actual documentation for the module() directive is https://bazel.build/rules/lib/globals#module.

There it also doesn't say anything about version format.

[Wyverald]

Just to confirm, 1.0.0.1 > 1.0.0rc1, right?

No; the comparison is lexicographical regarding dot-delimited sections, so 1.0.0 < 1.0.0.1 < 1.0.0rc1 < 1.0.1

EDIT: This is (partially) wrong: 1.0.0rc1 > 1.0.1. In fact, 1.0.0rc1 > 1.0.9, because 0rc1 is a string identifier that compares greater than any number identifier.

[Wyverald]

The actual documentation for the module() directive is https://bazel.build/rules/lib/globals#module.

There it also doesn't say anything about version format.

Indeed, I'll fix that ASAP.

[Wyverald]

It just occurred to me that we could mitigate the confusion by enforcing that the version list in metadata.json is sorted. That way, if a PR adds a new version and it's not at the end, you'll immediately see something is wrong.

[hobofan]

It looks like @cgrindel has implemented proper version support in renovatebot/renovate#21606 if I'm not mistaken.

Will have to see if/how we could also use that here (and maybe whether we can extract that in a separate repo, so that all JS/TS projects that need Bazel module version support can take advandtage of it)?