FR: version string convention to signify patched Bazel binary

[ghost]

Description of the problem / feature request:

I am requesting a documented convention which allows vendors to tag their builds of Bazel. Rule authors should then accommodate those conventions when conditioning code on Bazel's native.bazel_version.

Feature requests: what underlying problem are you trying to solve with this feature?

We backport patches from master, apply pending PRs, etc. to our internal builds of Bazel. To indicate to our users that they're not using vanilla Bazel, we append a +vmware to the version string:

$ bazel version
Starting local Bazel server and connecting to it...
Build label: 0.28.1+vmware
...

We now have users trying to use rules_nodejs, but their builds are failing because rules_nodejs has logic to parse Bazel's version, and it's choking on our +vmware suffix. Our options are now to either stop vendor-stamping our builds, or to (locally) patch rules_nodejs to ignore +.... I would prefer to adhere to a shared convention such that, after adjusting our stamping process to match said convention, we could instead submit a PR to rules_nodejs so that it supports the same scheme as well.

Have you found anything relevant by searching the web?

No.

I hadn't even heard of native.bazel_version until encountering its use in rules_nodejs. AFAICT it's undocumented on docs.bazel.build.

[philwo]

I think this is fine and supported by semantic versioning:

10. 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-]. (https://semver.org/#spec-item-10)