-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Respectful code cleanup: rename master
branch to main
#107
Comments
I plan to rename several sites on Monday 2021-06-28. That way if there is any fallout from automatic processes with a stale branch name I can be available to fix or advise. |
The branch is renamed |
I just installed Bazelisk, and then tried to build "mediapipe" project, which gives me 404. It seems like the branch renaming is the reason:
|
Yes. You would have to change that to main.zip. But... I think that is the wrong solution as well. You should not build your projects against the head of any dependencies. Doing that gives control over what goes into your project to someone else. The best thing to do is reference a named release. Unfortunately there are none, #91 Without that, freezing to a commit that you have tested against is the next best fallback. |
Seems like they fixed it now: google-ai-edge/mediapipe@374f5e2 |
Changed url and prefix for c++ rules to reflect renaming of branch as seen here: bazelbuild/rules_cc#107
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382526074
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382526074
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382526074
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382531776
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382544881
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382544881
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382544881
…ild/rules_cc#107 The longer term solution is: - To use a named release of rules_cc once that is available (See bazelbuild/rules_cc#91) - Wrap the `http_archive` rules with `maybe` so that there will not be conflicts if downstream users try to mix rules_cc versions. PiperOrigin-RevId: 382555074
Changed url and prefix for c++ rules to reflect renaming of branch as seen here: bazelbuild/rules_cc#107
Signed-off-by: Pierre Fenoll <[email protected]>
Changed url and prefix for c++ rules to reflect renaming of branch as seen here: bazelbuild/rules_cc#107
Same task with the same justification as bazelbuild/bazel#12200.
The text was updated successfully, but these errors were encountered: