What are the policies for rapidly changing modules and non-standard release versions?

[bazelbuild]

What are the policies for rapidly changing modules and non-standard release versions?

[Wyverald]

OK, so it sounds like the multiple-releases-per-day thing is expected to be the exception, not the norm, in which case I'm totally okay with this.

Also note that we don't intend every single released version of a project to be available in BCR, so you could also wait for a day before submitting a new release into BCR ("baking" it, if you will), if you really need to avoid the frequent updates.

[Wyverald]

cc @meteorcloudy

I don't believe we have a policy for frequent releases right now. Preferably only somewhat stable versions should be submitted to the central registry, but given the existence of "live at head" projects such as Abseil and upb, I think having unreleased/pre-release versions is unavoidable. The good thing is that we do support pre-release versions as denoted in the semver spec, so for abseil-cpp for example, you could create a "fake" version like "20221005-bcr.1" if necessary (let's try to keep the version format consistent within each module, as different projects have different versioning schemes).

Most of our modules only change weekly or monthly, but sometimes we cut several releases in a day.

What are these modules that you cut several releases per day for? My gut take is that we should at least attempt to limit the number of versions in the BCR, say with some arbitrary frequency cap (just throwing "1 per day" out there).

[aaronmondal]

@Wyverald Dependencies for rules_ll and rules_ll itself. Usually we only release like once or twice a month, but we've had a case before where we had to hotfix issues like 3 times within a few hours 😅 This is mostly not the case though, and a theoretical max cap like once a day is completely fine for us.

With rules_ll specifically, I'm not sure whether that should be in the BCR anyways, since we use custom overlays for things like abseil and I don't think it would be wise to have duplicates of all the C++ modules in the BCR just because we prefer our own API over rules_cc.

The bigger issue is the LLVM project, which I'm tracking in #206. But even there once a day would be way more often than what we can realistically keep up with continuously. I just wanted to make sure that IF there is a case where we have to hotfix something in some exceptional case that we have "headroom" for that.

So as long as there is no such rule like "1 per month max and only stable versions" things are totally fine for us 😊

"fake" version like "20221005-bcr.1" if necessary (let's try to keep the version format consistent within each module, as different projects have different versioning schemes).

I really like that versioning method. I'll start getting some PRs ready 😄

[meteorcloudy]

Just want to mention that PRs still take some time to review (possibly longer than 1 day), so even if you have multiple hot fixes for a release, it's likely that when we receive the PR for the last release we can just discard previous unmerged PRs.

I do know a use case that the project needs to depend on a specific commit and update the dependency multiple times in a day. TensorFlow: https://github.com/tensorflow/tensorflow/commits/master/third_party/llvm/workspace.bzl

In that case, it's probably easier for them to just use overrides (or just introduce the same dependency with a module extension) so that they won't get blocked by the BCR process.

[aaronmondal]

Closing as my questions have been answered ☺️