There should be periodic named releases. #91

aiuto · 2020-11-12T04:11:40Z

If there is no guidance about what commits are considered "good" (for various values of good), people will just use head. If people do that, debugging version skew problems is infeasible.

olekw · 2020-12-28T17:31:08Z

I'll also need an actual release to package properly for Debian. Is that feasible in the near-term? cc:@meteorcloudy

meteorcloudy · 2021-01-05T15:21:24Z

/cc @oquenchil Can we make a release for rules_cc?

aiuto · 2021-01-05T21:04:02Z

FWIW: After bazelbuild/bazel#12743 is merged, you should be able to update bazel to the new rules_cc with a 3 line change, single file change.

meteorcloudy · 2021-01-07T11:03:07Z

@aiuto That's not what we are looking for. We want to package rules_cc into Debian, so that Bazel doesn't have to download it from internet at all. To do that, we need a release for this project.

aiuto · 2021-01-07T16:32:53Z

@oquenchil @philwo

Ah.... I see a terminology difference. When we (Bazel) says release, we mean a versioned distribution archive that could be hosted on github. To you, that means a .deb package.

My concern was only about getting named versions to replace github hashes.
Getting from that to a .deb file in the right place will require answering some questions. Between us, I think we can come up with the answers. What we do for this will set a pattern/expectation for other rule sets to follow, so @philwo may want to chime in.

Questions and thoughts:

rules_pkg has .deb file building tools. We can add to that as needed.
Should the distribution be just source (essentially, all the files)?
Should we also have a binary distribution that excludes examples and tests?
Users will often need two versions installed at the same time when they are transitioning bazel versions.
- install to /usr/share/bazelbuild/rules_cc/VERSION/...
- in WORKSPACE
```
local_repository(name="rules_cc", path="/usr/share/bazelbuild/rules_cc/VERSION/")
```
How do we get from bazel build //distro:rules_cc.deb to the Debian repository?
- Should rules_pkg have scripts which aid in this?
- Do we have to sign them? will someone need a secure pipeline for signing them?
- Is it sufficient for the Bazel team to create the .deb file at the same time they do the versioned .tar file?

meteorcloudy · 2021-01-08T09:47:03Z

Ah.... I see a terminology difference. When we (Bazel) says release, we mean a versioned distribution archive that could be hosted on github. To you, that means a .deb package.

No, what we want are the same, we also just need a versioned distribution archive, which is not available right now. @olekw will kindly help us create the deb package and get it into the Debian distribution.

The deb package will essentially only contains Bazel files. It would great if we can exclude unnecessary file in the release archive.

oquenchil · 2021-01-08T10:16:39Z

I will create the release for rules_cc on GitHub, I was a bit hesitant because we deem rules_cc a mistake and we shouldn't have created it before finishing starlarkifying the rules. We don't plan on deleting the repository now because that would be a lot of hard work but we hope to spend as little time on the repo as possible in the short term.

I will document that the release is not part of an official process, there is no guaranteed release cycle and it just exists to support Debian packaging. I will name the first release 0.1.

olekw · 2021-03-25T14:55:03Z

@oquenchil That would be great! Any progress on that?

olekw · 2021-04-05T16:35:13Z

To clarify, we don't need a "binary" release to package this in Debian. We just need a source release since we build everything from source anyway. So just a "0.1.0" release tag would suffice for our purposes.

olekw · 2021-04-05T16:37:22Z

On a loosely-related question, what's the long-term plan, @oquenchil? Are you planning to refactor the code for rules_cc or just integrate that functionality directly into core Bazel?

catleeball · 2021-04-23T06:10:57Z

I was a bit hesitant because we deem rules_cc a mistake and we shouldn't have created it before finishing starlarkifying the rules.

Do you know when the new starlark rules will be released? And will they replace the contents of this repository, or be uploaded elsewhere?

…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: 382555074

Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc. However rules_cc was always saying that there is no need to use them yet. After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it. One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit: bazelbuild/rules_cc#91 bazelbuild/rules_cc#68 The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc. More information about the discussions: bazelbuild/rules_cc#86 bazelbuild/rules_cc#92 bazelbuild/buildtools#923 bazelbuild/buildtools#952 Fixes bazelbuild#2949

Long time ago Bazel was saying that cc_binary, cc_library, cc_test and the other cc_* rules should be imported from rules_cc. However rules_cc was always saying that there is no need to use them yet. After several discussions it was clarified that migration to bazelbuild/rules_cc was put on hold and there is not need to the users that they start using it. One of the reasons why a person would not want to use rules_cc right now is because there is no release and there is no notion of what is a good commit: bazelbuild/rules_cc#91 bazelbuild/rules_cc#68 The fact that rules_go depends on rules_cc forces any rules_go user to use rules_cc. Considering that rules_docker depends on rules_go, any rules_docker user is also forced to depend on rules_cc. More information about the discussions: bazelbuild/rules_cc#86 bazelbuild/rules_cc#92 bazelbuild/buildtools#923 bazelbuild/buildtools#952 Fixes: #2949

meteorcloudy · 2021-09-24T13:08:45Z

@oquenchil This is also blocking bazelbuild/bazel-central-registry#7

philwo · 2021-09-24T13:30:32Z

I'd recommend to just start doing releases here as @oquenchil said with 0.x - this tells the user that there's no promise of any compatibility between the versions.

oquenchil · 2021-09-24T13:44:54Z

I will take care of it next week.

limdor · 2021-10-13T10:54:04Z

@philwo could it be possible to have https://github.com/bazelbuild/rules_cc/releases/download/0.0.1/rules_cc-0.0.1.tar.gz also in the bazel mirror? Thanks

* Remove bazelbuild/rules_cc dependency The Bazel team recommends using native rules nowadays: bazelbuild/rules_cc#91 (comment) Abseil stopped depending on `rules_cc` in abseil/abseil-cpp@b2387f0.

philwo · 2021-10-19T12:45:28Z

@limdor Uploaded!

meteorcloudy · 2021-10-21T14:26:36Z

Looks like this issue can be closed, thanks for the effort!

aiuto mentioned this issue Jun 28, 2021

Respectful code cleanup: rename master branch to main #107

Open

copybara-service bot mentioned this issue Jul 1, 2021

Update reference to rules_cc to main.zip. This is required by https://github.com/bazelbuild/rules_cc/issues/107 google/XNNPACK#1603

Merged

copybara-service bot mentioned this issue Jul 1, 2021

Update reference to rules_cc to main.zip. This is required by https://github.com/bazelbuild/rules_cc/issues/107 google/XNNPACK#1604

Merged

limdor mentioned this issue Sep 6, 2021

Remove dependencie with bazelbuild/rules_cc bazelbuild/rules_go#2949

Closed

limdor mentioned this issue Sep 9, 2021

Remove dependencie with bazelbuild/rules_cc bazelbuild/rules_go#2950

Merged

meteorcloudy mentioned this issue Sep 24, 2021

Modularize core Bazel dependencies bazelbuild/bazel-central-registry#7

Closed

20 tasks

dinord mentioned this issue Oct 14, 2021

Remove bazelbuild/rules_cc dependency google/cctz#203

Merged

oquenchil closed this as completed Oct 27, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

There should be periodic named releases. #91

There should be periodic named releases. #91

aiuto commented Nov 12, 2020

olekw commented Dec 28, 2020

meteorcloudy commented Jan 5, 2021

aiuto commented Jan 5, 2021

meteorcloudy commented Jan 7, 2021

aiuto commented Jan 7, 2021

meteorcloudy commented Jan 8, 2021

oquenchil commented Jan 8, 2021

olekw commented Mar 25, 2021

olekw commented Apr 5, 2021

olekw commented Apr 5, 2021

catleeball commented Apr 23, 2021 •

edited

meteorcloudy commented Sep 24, 2021

philwo commented Sep 24, 2021

oquenchil commented Sep 24, 2021

limdor commented Oct 13, 2021

philwo commented Oct 19, 2021

meteorcloudy commented Oct 21, 2021

There should be periodic named releases. #91

There should be periodic named releases. #91

Comments

aiuto commented Nov 12, 2020

olekw commented Dec 28, 2020

meteorcloudy commented Jan 5, 2021

aiuto commented Jan 5, 2021

meteorcloudy commented Jan 7, 2021

aiuto commented Jan 7, 2021

meteorcloudy commented Jan 8, 2021

oquenchil commented Jan 8, 2021

olekw commented Mar 25, 2021

olekw commented Apr 5, 2021

olekw commented Apr 5, 2021

catleeball commented Apr 23, 2021 • edited

meteorcloudy commented Sep 24, 2021

philwo commented Sep 24, 2021

oquenchil commented Sep 24, 2021

limdor commented Oct 13, 2021

philwo commented Oct 19, 2021

meteorcloudy commented Oct 21, 2021

catleeball commented Apr 23, 2021 •

edited