Post Mortem: Yank rules_cc@0.1.0

[hofbi]

I would like to use this discussion to fully understand the problem and if we can get some learnings out of this.

Problem

Merging of #3582 broke many packages on BCR itself as well as on other repos, e.g. the boost packages that are bumped in #3585.

Expectation

Marking an existing version as yanked should not break existing build, but only result in a different version selection.

Question

Without knowing all the details about the Go's minimal version selection (MVS) referenced here, my hypothesis is that packages where broken because 0.1.0 is the highest version number available. Hence MVS cannot go below that version if it is referenced by at least one package.

In case, there would have been an 0.1.1 or anything > 0.1.0 available, would MVS have used this version instead?

[meteorcloudy]

Marking an existing version as yanked should not break existing build, but only result in a different version selection.

This would mean the resolution result will depend on the state of the BCR, which is what we want to avoid to ensure reproducibility.

[hofbi]

But yanking the version is a state change, and it affected many projects. How is that different?

[fmeum]

It's a state change in the sense that it can turn a successful resolution into one that fails, but it can't affect the outcome of a successful resolution. The latter is important for reproducibility.

That said and as I only fully grasp now, this case of yanking is particularly breaking since there is no more recent version that users can update to via a bazel_dep. Instead, they have to pin the downgrade via single_version_override until the entire dependency closure has downgraded.

@meteorcloudy We should probably unyank the version for now and then yank it again after a higher version has been released.

[hofbi]

That said and as I only fully grasp now, this case of yanking is particularly breaking since there is no more recent version that users can update to via a bazel_dep. Instead, they have to pin the downgrade via single_version_override until the entire dependency closure has downgraded.

Exactly, this is what I wanted to understand and tried to explain with

In case, there would have been an 0.1.1 or anything > 0.1.0 available, would MVS have used this version instead?

But my expectation would have been to fix it by running bazel mod update, hence unyanking this might help to fix a few projects.

As another potential outcome of this, would it help to have a check that you cannot yank the highest version number available?

[fmeum]

What is bazel mod update? I don't think we have that yet.

Yes, such a check would be useful. Yanking happens so rarely that we would probably notice this the next time it happens though.

[hofbi]

Sorry, bazel mod tidy it is.

Created #3604 for the "do not yank latest version" check.

[meteorcloudy]

In case, there would have been an 0.1.1 or anything > 0.1.0 available, would MVS have used this version instead?

No, only appeared version in the dependency graph will be selected, MVS will not bump to a unreferenced version.