Follow up to #1210

Thanks!

Thanks for the fix @kgreenek! Can a new release be cut with this fix? This is blocking the update to rules_cc==0.1.0 for us.

@ryanli FYI The rules_cc authors actually yanked 0.1.0. It's recommended to use 0.0.17, which is newer than 0.1.0 and still has the cc_proto_library defined for now. All the packages in the BCR that depended on rules_cc==0.1.0 were updated to use rules_cc==0.0.17 instead.

That being said, +1 for a new release with this change. That would unblock everything that depends on this when rules_cc does eventually remove the cc_proto_library macro

It was added back to main to bazelbuild/rules_cc@28cf2e8 but I don't see 0.1.0 yanked in BCR. But yeah, the point still stands.

They did yank it, but it turns out yanking the highest version number causes problems downstream, because there is essentially no way to get a valid version when you do that besides using single_version_override.

The did a post-mortem and added a CI check to disallow yanking the highest version of anything in BCR.

Here's the PR where they unyanked it:
bazelbuild/bazel-central-registry#3603

Version 0.0.14 and 0.1.0 should be avoided.

protoc-gen-validate 1.2.1 has been released with this change.

@nicksnyder Would you be willing to push the latest version to the BCR?

It's a pretty straight-forward process if you haven't done it before. I'm happy to do it, but want to encourage folks in the community to publish to the BCR whenever possible.

Looks like somebody already created a MODULE.bazel file too for 1.0.4 (see version 1.0.4.bcr.2).

See:
https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/protoc-gen-validate
https://registry.bazel.build/modules/protoc-gen-validate

We haven't pushed to the BCR before. Abstractly happy to do it but would want it either automated in CI (if possible) or a documented process anyone could follow. Would you be willing to contribute a PR that does one of those (add CI or add a README)?