0.8.1 release dropped bzlmod compatibility_level to 0

[alexeagle]

https://registry.bazel.build/modules/rules_pkg

Causes errors for any user who has transitive dependencies that reach to conflicting compatibility_levels

ERROR: Error computing the main repository mapping: protobuf@21.7 depends on rules_pkg@0.7.0 with compatibility level 1, but <root> depends on rules_pkg@0.8.1 with compatibility level 0 which is different

Reported in bazel-contrib/rules_oci#99 and by @brentleyjones in Bazel slack
https://bazelbuild.slack.com/archives/C014RARENH0/p1679686451590549

There's some context in that slack thread with @Wyverald about how to repair this.

[aiuto]

It probably should be 2 now. What would be helpful is better guidance about how compatibility level is intended to be used. Is it about API surface, or about the API surfaces it uses? That is, will updating the version of X require updates in the dependencies as well. That is a reasonable interpretation, but leads to churn.

[brentleyjones]

It should only be for breaking exposed API changes. Shouldn't have anything to do with dependencies.

@Wyverald also suggest that not every breaking change increment it (but I'm more of a SemVer purist here).

Also, without bazelbuild/bazel#17572, compatibility version bumps can be pretty disruptive. Did rules_pkg change its API?

(Btw, why does protobuf expose rules_pkg as a non-dev dependency?)

[aiuto]

Did rules_pkg change its API?

Well... the current sources have breaking changes to the format of the manifest file. That is supposed to be private, but I know people are using it at their own risk.

I think the right thing to do is go to 0.9.0 and compatible=2 ( #687 )
But who knows what will happen to people who like to update to head all the time.

(Btw, why does protobuf expose rules_pkg as a non-dev dependency?)
I have no idea. I didn't even know they used it.

[alexeagle]

0.9.0 is published with compat_level 1 which I think is sufficient to fix this, thanks

[brentleyjones]

Do we want to yank 0.8.1?

[alexeagle]

I don't know if that makes things better or worse. It would be nice if registry.bazel.build showed which modules already declared a dependency on that version. 0.8.1 was live for 7 weeks so I imagine there are several.
Yanking it would break those modules, or not break them? If nothing in the graph requests 0.9.0 I don't know what bzlmod would do.

[Wyverald]

If nothing in the graph requests 0.9.0 I don't know what bzlmod would do.

Well, it would fail, obviously :) So yeah, yanking probably doesn't do too much good in this case. But at least it could provide an error message saying "hey, please use 0.9.0, and/or upgrade your deps to versions that use 0.9.0"

[aiuto]

I think the missing feature here is that I should be able to write

bazel_dep(name = "rules_pkg", compatibility_level = 1)
or
bazel_dep(name = "rules_pkg", version = "0.7.*")

and get the newest version at that level.
It should mostly be top level users that care about dependencies and want to specify specific versions.
Most rules that depend on other rules don't have to point to specific versions. They care about about some interpretation of semantic versioning. What is confusing here is that we have two things that are indented to mean it, the version and compatibility_level.

[brentleyjones]

Version just sets a minimum version and an implied a maximum version (via the compatibility level of that version). Both of the ways you set wouldn't let us use MVS.

So rules should just depend on the minimum version they can, while top level projects should depend on they maximum version they can (that their dependencies support).

[aiuto]

So rules should just depend on the minimum version they can,

Exactly. That's why I am not a fan of auto-update bots like rennovate.