[Proposal] Change BCR-only version naming pattern

[armandomontanez]

I'd like to rethink our BCR-only release naming, in part to support bazelbuild/bazel#23461 and other floating releases that don't map to official releases.

Proposal

Recommend +bcr.<N>.<short Git SHA>, where the .<short Git SHA> is an optional indicator for intermediate releases that aren't associated with an official release. Note that <N> should always be incremented to ensure version ordering is maintained, as git hashes aren't suitable for semver ordering.

Examples:

• 1.234.456 - An official release with no BCR-only changes.
• 0.0.1-RC1 - An official release candidate with no BCR-only changes.
• 1.234.456.AS-1333.2024.09.14 - An official release that doesn't strictly follow semver.
• 1.234.456+bcr.1 - An official release that involves a BCR-related patch.
• 1.2.3-RC2+bcr.1 - An official release candidate that involves a BCR-related patch.
• 1.0.1-develop+bcr.17.dd7336eca - The 17th BCR-only release for the develop channel for 1.0.1.
• 2.0.3+bcr.1.dd7336eca - A BCR-only release for a floating commit after the v2.0.3 release but before the next official release.
• 1.234.456.AS-1333.2024.09.14+bcr.1 - An official release that doesn't strictly follow semver and involves a BCR-related patch.

Justification

Semver major.minor.patch has specific semantic intent for the patch portion of the version string. While placing . separators in/following the patch string are not explicitly prohibited, semver requests patch is an integer and prescribes ways to append additional information:

• A pre-release version may be denoted by appending a hyphen
• Build metadata may be denoted by appending a plus sign

While many projects elect to use the hyphen to denote pre-releases (e.g. -RC1, -develop, -pre.1), using the plus in official releases of source code is quite rare (anecdotally). This means it's less likely that BCR versions will ever collide with this nomenclature, and it's much more visually distinct when a given version has BCR-only changes.

[Wyverald]

The justification part doesn't make sense to me, since Bazel module versions are a strict superset of SemVer, not the other way around. So version strings on the BCR are intentionally not always valid SemVer; conversely, any SemVer is a valid Bazel module version. See https://bazel.build/external/module#version_format for more info.

The other problem with this proposal is that it breaks the invariant that "two SemVer versions a and b compare a < b if and only if the same holds when they're compared as Bazel module versions". In SemVer, 1.0.0+bcr.1 compares equal to 1.0.0+bcr.2. With this proposal, Bazel would consider one to be newer than the other.

[Wyverald]

Also, this sentence:

While placing . separators in/following the patch string are not explicitly prohibited,

is incorrect AFAIK. SemVer has to have three segments in the "release" part, and each has to be a number. A string like 1.2.3.4 or 1.2.3.bcr.1 are explicitly invalid SemVer.

[armandomontanez]

Now that you point that out, SemVer does explicitly say Build metadata MUST be ignored when determining version precedence. which kind of kills this idea.

Where does the implementation of Bzlmod's version handling live? I'm realizing that there will be a brick-wall reception to anything that requires changes to that due to the interoperability nightmare it'd introduce.

[fmeum]

https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/bazel/bzlmod/Version.java;l=65