Bazel 0.18.0 release candidate 6 is available for testing

[Klaus Aehlig]

Bazel 0.18.0rc6 is now available for those that want to try
it out.

You can download it from:
https://releases.bazel.build/0.18.0/rc6/index.html

Please report regressions to https://github.com/bazelbuild/bazel/issues as soon
as possible.

The release notes for version 0.18.0 are:

# Release 0.18.0rc6 (2018-09-28)

Baseline: c062b1f1730f3562d5c16a037b374fc07dc8d9a2

Cherry picks:

+ 2834613f93f74e988c51cf27eac0e59c79ff3b8f:
Include also ext jars in the bootclasspath jar.
+ 2579b791c023a78a577e8cb827890139d6fb7534:
Fix toolchain_java9 on --host_javabase=<jdk9> after
7eb9ea150fb889a93908d96896db77d5658e5005
+ faaff7fa440939d4367f284ee268225a6f40b826:
Release notes: fix markdown
+ b073a18e3fac05e647ddc6b45128a6158b34de2c:
Fix NestHost length computation Fixes #5987
+ bf6a63d64a010f4c363d218e3ec54dc4dc9d8f34:
Fixes #6219. Don't rethrow any remote cache failures on either
download or upload, only warn. Added more tests.

- New bazelrc file list.
- Adds --incompatible_expand_directories to automatically expand
directories in skylark command lines. Design doc:
https://docs.google.com/document/d/11agWFiOUiz2htBLj6swPTob5z78TrC
xm8DQE4uJLOwM
- --incompatible_package_name_is_a_function now defaults to true.
The magic values PACKAGE_NAME and REPOSITORY_NAME are no longer
exposed.

New features:

- Add --modify_execution_info, a flag to customize action execution
info.

Important changes:

- A new, experimental, options --experimental_ui_deduplicate was
added that
makes the UI try to deduplicate messages from actions to keep
the output on the
console cleaner.
- Add ExecutionInfo to aquery output for ExecutionInfoSpecifier
actions.
- The Android resource processing pipeline now supports persistence
via worker processes. Enable it with
`--persistent_android_resource_processor`. We have observed 1.5x
faster clean local builds, and up to 2.5x faster incremental
local builds.
- --windows_exe_launcher is deprecated, this flag will be removed
soon. Please make sure you are not using it.
- CppRules: cc_binary link action no longer hardcodes
-static-libgcc for toolchains that support embedded runtimes
(guarded by --experimental_dont_emit_static_libgcc temporarily).
- When computing --instrumentation_filter, end filter patterns with
"[/:]" to match non-top-level packages exactly and treat
top-level targets consistently.
- Note
- The startup flag --host_javabase has been renamed to
--server_javabase to avoid confusion with the build flag
--host_javabase.
- objc_library now supports the module_name attribute
- Added "bazel info server_log" command to obtain the main Bazel
server
log file path, which can be quite useful for debugging Bazel
issues.
- Support fileset expansion in ctx.actions.args(). Controlled by
--incompatible_expand_directories.
- Fixes aapt shrink resources not respecting filters configurations
- --javacopt= no longer affects compilations of tools that are
executed during the build; use --host_javacopt= to change javac
flags in the host configuration.
- Revert the default of --incompatible_package_name_is_a_function
to false.
- Future versions of Bazel will require a locally installed JDK
for Java development. Previously Bazel would fall back to using
the
embedded --server_javabase if no JDK as available. Pass
--incompatible_never_use_embedded_jdk_for_javabase to disable the
legacy
behaviour.
- Fix regression #6219, remote cache failures


--
Klaus Aehlig
Google Germany GmbH, Erika-Mann-Str. 33, 80636 Muenchen
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschaeftsfuehrer: Paul Terence Manicle, Halimah DeLaine Prado

[erik....@abelee.com]

Hi,

  - New bazelrc file list. 

this release breaks tools/bazel.rc (as of rc6). Shouldn't there be a cycle of releases with deprecation and warnings first?

Digging through the mailing list and issues, tools/bazel.rc is the recommended approach for adding per project configuration defaults. See tensorflow as an example https://github.com/tensorflow/tensorflow/blob/master/tools/bazel.rc

I'm not sure I see a clean way of migrating our developers. Either we need to forcefully overwrite .bazelrc. tell all developers to make changes manually. or we need to add a workaround to tools/bazel. What's your recommended approach here? Apologies if this is already written somewhere. I didn't find it with a few google searches, and the release note is not helping.

-- 

Erik Cysneiros Gorset

[Klaus Aehlig]

On Fri, Sep 28, 2018 at 03:17:36PM -0700, erik....@abelee.com wrote:
> Hi,
>
> - New bazelrc file list.
>
>
> this release breaks tools/bazel.rc (as of rc6). Shouldn't there be a cycle
> of releases with deprecation and warnings first?

The commit in question is https://github.com/bazelbuild/bazel/commit/5e5ee0db8f1925bcf9ac39232faa0622966d7e2a

Chloe, did we have a release with a warning so far? If not, how should we
proceed?

> I'm not sure I see a clean way of migrating our developers.

Woudln't a clean way be adding

import %workspace%/tools/bazel.rc

to the .bazelrc in the top-level directory of the workspace for all projects
depending on tools/bazel.rc?

Thanks,
Klaus

[Chloé Calvarin]

This is issue #4502, along with CI fixes in #5756 and the transition-pain related followup issue #5765. 

Unfortunately, our usual way of transitioning breaking changes is to put them behind a flag, but the bazelrc controls which flags are set, so that doesn't really work. Talked about this in https://github.com/bazelbuild/bazel/issues/5756#issuecomment-410283229. We added try-import to make it possible to add "try-import %workspace%/tools/bazel.rc" in your workspace/.bazelrc, (#5765) to support having both old and new bazels running in the same workspace.

[Erik Gorset]

Hi,

thanks for the followup. It looks like I'm late to the table on this one.

I would highly recommend rolling back this behavior. At least keep reading tools/bazel.rc for now until it's possible to transition between two adjacent versions without breakage.

Just looking for a couple minutes I find a few interesting projects using tools/bazel.rc:

https://github.com/grpc/grpc/blob/master/tools/bazel.rc

https://github.com/envoyproxy/envoy/blob/master/tools/bazel.rc

https://github.com/apache/incubator-heron/blob/master/tools/bazel.rc

https://github.com/spotify/bazel-tools/blob/master/tools/bazel.rc

It sounds like we either have to choose between manually adding "import %workspace%/tools/bazel.rc" to .bazelrc or overwriting existing .bazelrc with "try-import %workspace%/.bazel-user.rc" (as an example).

Just to be clear, before 0.18 we got:

tools/bazel.rc - project default, checked into git

.bazelrc - user configuration, covered by .gitignore

It's painful to move between branches when a file is changed from being covered by .gitignore to an actual checked in file. I see gerrit chose to move tools/bazel.rc to .bazelrc. That overwrites any local user configuration, but that might be better than having to do it manually.

If we need to manually add the try-import to .bazelrc, then it means you have broken the optimal flow that would be something like:

1. git clone repo

2. cd repo

3. bazel build //...

We would need a new third step that says, manually create a .bazelrc that imports tools/bazel.rc.

Sure, we can add our own tooling for this. We use tools/bazel to make sure the correct bazel version is used, so we could modify it to patch .bazelrc accordingly. But come on, wouldn't it be better for everyone to just keep tools/bazel.rc?

-- 

Erik Cysneiros Gorset

[Chloé Calvarin]

I disagree - I really do think we need to change these files. In particular, regarding keeping the old project-file - many projects don't have or want to have a tools/ subdirectory, it doesn't get used anywhere else and is direct legacy behavior from the Google-internal repository structure which makes no sense for most Bazel projects. I agree there's some transition pain, but the old rc state made no sense, and to fix this is a breaking change, so we have to do it before bazel 1.0 if we're ever going to clean it up. 

For the record, the %workspace%/.bazelrc duality pre- and post- change is something I mentioned getting around in #5765 with renaming the file, but I was outvoted by folks who preferred to have try-import to add flexibility. Everyone has different opinions here, what we need is just a system that works, is documented, and doesn't interfere with itself the way the old one did. 

I no longer work on this team though, so current owners should make a call here.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAOv6%2B8QZMtzsfS73V22spJnRqA_-8%3DuEGmuCesAnBJSCYgJsEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Laurent Le Brun]

Since users rely on the old behavior, can we roll back instead of breaking their build?

For a smoother rollout, we can follow https://docs.google.com/document/d/1Dj5PBLmPVg9ZyApm4GobM3y-mDgY3mVaqpRVttOe-ZQ/edit (even if it's not formally approved yet).

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAMe9KXAbAtdSa9F2%2BzR8yODp6h2FhmOpdkq7j1fWoSjGUic_Tw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Laurent

[Chloé Calvarin]

As I already said, the general breaking changes policy you link to cannot apply. It relies on flags and on the Bazel server configuration. bazelrcs are the first thing to be parsed, we do this long before we know anything else about the build, so the standard suggestion doesn't work. 

The best we can do is warn people if what they have isn't working - which is in the current change.

Chloé

[Laurent Le Brun]

Oops, sorry, I misread.

Still, this is a breaking change and users were not notified in advance. This means that many projects rely on tools/bazel.rc. This is actually what the website recommends to do: https://docs.bazel.build/versions/master/best-practices.html#bazelrc

So if anyone updates Bazel and uses it before the project maintainers have updated the project, they'll get a failure.

For a better user experience, I recommend:

 - Add the warning, but keep the old behavior.

 - Wait at least one release (the migration window), to give some time for maintainers to update their code.

 - Later, switch the behavior.

Also, we could improve the message. "... please transfer their contents or import their path into one of the standard rc files ...". We could add a link to the relevant documentation, because it will not be obvious for everyone how to import the path or what are the standard rc files.

--

Laurent

[Klaus Aehlig]

On Tue, Oct 02, 2018 at 08:12:15PM -0400, Laurent Le Brun wrote:
> For a better user experience, I recommend:
> - Add the warning, but keep the old behavior.
> - Wait at least one release (the migration window), to give some
> time for maintainers to update their code.
> - Later, switch the behavior.

What does this mean for the release? Is it a releaes blocker or
just a "that would have been the nicer way of doing it"?

If it is a release blocker, is anyone actually working
on the "warning, but keep old behavior" change? Note that
5e5ee0db8f1925bcf9ac39232faa0622966d7e2a cannot be cleanly reverted.
Also, do we know that no one is relying on the new behaviour already
(some people do use bazel at HEAD)?

I guess that means, the release slips by another week; with BazelCon
upcoming, if we don't release today, we won't do it before Oct 15.

[Erik Gorset]

On Thu, 4 Oct 2018 at 09:59, Klaus Aehlig <aeh...@google.com> wrote:

On Tue, Oct 02, 2018 at 08:12:15PM -0400, Laurent Le Brun wrote:
> For a better user experience, I recommend:
>  - Add the warning, but keep the old behavior.
>  - Wait at least one release (the migration window), to give some
>    time for maintainers to update their code.
>  - Later, switch the behavior.

What does this mean for the release? Is it a releaes blocker or
just a "that would have been the nicer way of doing it"?

As an external user of bazel, I would appreciate that it was a release

blocker. I assume most users of bazel don't spend too much time on

the mailing list, github issues, or testing out release candidates, so

I'm guessing this change will come as a surprise to many adopters.

As a minimum, the release note should describe what is changing

and what users must do to adopt the new behavior. However, it's

actually not obvious to me how to do this in the best way. The question

is, what's the best practice for implementing project defaults with

user overrides? This used to be tools/bazel.rc (for project default,

under version control) and .bazelrc (for user overrides, ignored by

version control).

Please correct me if I've misunderstood something, but the possible

solutions I see are:

1. Put .bazelrc under version control and use try-import to import

.bazelrc-user-overrides (name chosen for demo purposes). This

requires manual work for all developers that already has a custom

.bazelrc.

2. Make projects default opt-in by requiring the user to ad import

tools/bazel.rc to their .bazelrc. This is problematic because we then

have the dependency graph: project -> user overrides -> project defaults

and it means many projects are broken by default until .bazelrc

is setup correctly.

Both means the file for project defaults or user overrides is

changed from something standard to something ad-hoc. If this

is really wanted, I would hope that the best practice page would

be updated with a recommended solution so that the community

has less fragmentation across projects.

-- 

Erik Cysneiros Gorset

[Klaus Aehlig]

> As a minimum, the release note should describe what is changing
> and what users must do to adopt the new behavior.

In the current draft of the release announcement, we have the following
statement.

* New [bazelrc file
list](https://docs.bazel.build/versions/master/user-manual.html#where-are-the-bazelrc-files).
If you need to keep both the old and new lists of .rc files
active concurrently to support multiple versions of Bazel,
you can import the old file location into the new list using
`try-import`. This imports a file if it exists and silently
exits if it does not. You can use this method to account for
a user file that may or may not exist.

[Philipp Wollermann]

IMHO:

Let's keep the change, get the release out and document this behavior change well and visibly in the release announcements.

Projects will need to move their tools/bazel.rc to .bazelrc when (!) they upgrade to a newer version of Bazel.

However, there's no immediate time pressure for users to upgrade - send your developers a mail that the file will move from tools/bazel.rc to .bazelrc and give them two weeks to do it. Only then actually upgrade Bazel for your company / project and do the move in the same commit.

I don't see why Bazel itself has to delay the release.

Of course we should also acknowledge that we could have handled this better and then do it better next time.

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/20181004093117.GA57133%40google.com.

For more options, visit https://groups.google.com/d/optout.

--

Philipp Wollermann
Software Engineer
phi...@google.com

Google Germany GmbH
Erika-Mann-Straße 33
80636 München

Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

Diese E-Mail ist vertraulich. Falls sie diese fälschlicherweise erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich bitte wissen, dass die E-Mail an die falsche Person gesendet wurde.

This e-mail is confidential. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

[Philipp Wollermann]

> give them two weeks to do it.

Sorry, with that I mean handling any eventually existing-but-gitignored .bazelrc in their repo.

May I ask - what do people actually put in there? What's the use case for this file?

[Chloé Calvarin]

The typical use case would be that the project defines configurations, and the per-user-per-rc file would specify which config they want on by default.
For the email/blog warning with instructions for how to migrate - Is anyone on the bazel team available to help me with that? I'm happy to draft something and help out, but I'm out of touch with the release process timeline, so someone on the team would be best suited to know the best time and place to send the message.

Chloé

[Laurent Le Brun]

I have just tried grpc.

$ git clone https://github.com/grpc/grpc.git

$ cd grpc

$ bazel build :all

...

INFO: Build completed successfully, 1554 total actions

$ bazel version

Build label: 0.17.2

$ bazel18 build :all

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:

/tmp/grpc/tools/bazel.rc

INFO: Analysed 84 targets (0 packages loaded).

INFO: Found 84 targets...

ERROR: /tmp/grpc/BUILD:2137:1: C++ compilation of rule '//:grpc_opencensus_plugin' failed (Exit 1)

In file included from ./src/cpp/ext/filters/census/grpc_plugin.h:25:0,

                 from src/cpp/ext/filters/census/server_filter.cc:29:

./include/grpcpp/opencensus.h:23:2: error: #error OpenCensus for gRPC is only supported when building with bazel.

 #error OpenCensus for gRPC is only supported when building with bazel.

  ^~~~~

INFO: Elapsed time: 6.089s, Critical Path: 2.96s

INFO: 90 processes: 90 linux-sandbox.

FAILED: Build did NOT complete successfully

I believe Bazel 0.18 is going to break a non-negligeable number of projects. If we proceed, we're basically asking all those projects to do an emergency fix to their code (or get user complains as soon as their users update to 0.18). I also don't think an end-user (who's probably not familiar with Bazel) would be able to fix the problem on their own, by just reading the error message.

--

Laurent

[Tobias Werth]

What do we win by just delaying that change?

How would we know it's "safe" to roll out the change again?

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFtxR%2Bnp8_JWqc7ndctqGuJmBq99MzYPoJ_0G_zpx3vHwQarAw%40mail.gmail.com.

[Laurent Le Brun]

So my recommendation is to roll back the change and release Bazel 0.18 without it.

If someone wants to own the work, I would encourage them to:

 1. Update the documentation.

 2. Add warning (without changing the behavior). It's likely downstream projects will update their code (if they don't, it's their problem). Also, improve the warning message to be more beginner-friendly.

 3. Later, one version later (so possibly in 0.20), change the behavior.

--

Laurent

[Chloé Calvarin]

This is a change to the way bazel runs, not to rules - the transition should not be invasive. Since there's no way to guard it, delaying it only adds an additional warning for a month that a change is coming. 

I don't personally think that helps much, but if the Bazel team cares to do this, someone needs to be assigned to add the warning and do the rollforward.

Chloé

[Erik Gorset]

Bazel should support tools/bazel.rc - this can be defended by looking at the number of high profile projects using it. There's a legitimate need for it.

Seen from the outside - you are removing a feature that you recommend as best practice and something that's used by a number of high profile projects.

 - Erik

[Chloé Calvarin]

We aren't removing the feature - we are moving the location of the file. The ability to have a per-project file still exists, it is just now in workspace/.bazelrc

This confused a lot of people - if a project put a rc file there before, it would override the user's home/.bazelrc. Changing this is to make it easier in the future.

Chloé

[musiccom...@gmail.com]

How about applying something minimal like this:

diff --git a/src/main/cpp/option_processor.cc b/src/main/cpp/option_processor.cc
index 04f7f4f8ff..373a8813f4 100644
--- a/src/main/cpp/option_processor.cc
+++ b/src/main/cpp/option_processor.cc
@@ -322,6 +322,7 @@ blaze_exit_code::ExitCode OptionProcessor::GetRcFiles(
SearchNullaryOption(cmd_line->startup_args, "workspace_rc", true)) {
const std::string workspaceRcFile =
blaze_util::JoinPath(workspace, kRcBasename);
+ rc_files.push_back(blaze_util::JoinPath(workspace, "tools/bazel.rc"));
rc_files.push_back(workspaceRcFile);
}

This essentially undeprecates tools/bazel.rc as a workspace config location, but still allows for migration to .bazelrc. (It doesn't help with the other locations that moved, but tools/bazel.rc seems to be the real sticker here.)

[Chloé Calvarin]

If we do roll this back, I propose the following sequence for the rollforward, an elaboration on what Laurent is suggesting

Bazel 19 - try-import & the warning about the old-v-new file locations that already exists. The difference would be that the old files are still being read. The same warning mechanism should be in place - the warning only exists if there is still a file that will get ignored in the new case, which means that the new files need to be parsed for import statements that would cover the old file locations. This will minimize warning spam once users are ready for the migration.  "try-import" should help users with this preparation for files that don't exist yet. The warning can link to a blog post if we want to provide more specific instructions / help.
Bazel 20 - flip which file set is being imported, the same warning can basically be kept with different wording. We could also consider making it an error, but that would make it difficult to support both old and new bazels in a workspace.
Bazel 21 - remove the warning, and the code that supports calculating the old file list for the diff calculation.

One thing we can't do is create an intermediate state, some sort of gradual transition - as soon as we have a set of files, Hyrum's law applies, so we have to do this in one version.

Chloé

[Erik Gorset]

On Thu, 4 Oct 2018 at 16:51, Chloé Calvarin <ccal...@google.com> wrote:

We aren't removing the feature - we are moving the location of the file. The ability to have a per-project file still exists, it is just now in workspace/.bazelrc

This confused a lot of people - if a project put a rc file there before, it would override the user's home/.bazelrc. Changing this is to make it easier in the future.

There's definitely confusion here. You are removing a feature, but not the feature you are describing.

Bazel supports two per-project rc files. The official best practice document [0] says you should use tools/bazel.rc for project defaults and .bazelrc for user configuration - this is the feature you are removing/breaking. With this feature removed, we need to choose if .bazelrc should act as user configuration (covered by .gitignore) or project defaults (checked into git). I'm sure we can manage to live with it by using import/try-import one way or another, but it is making life harder for us early adopters...

[0] https://docs.bazel.build/versions/master/best-practices.html#bazelrc

 - Erik

 

[Chloé Calvarin]

Yes - this was discussed in isse #5765. I made a suggestion to keep both, https://github.com/bazelbuild/bazel/issues/5765#issuecomment-411190895, but was overruled in favor of try-import. ¯\_(ツ)_/¯

Chloé

[Erik Gorset]

Hehe, ok. I apologize for not reading all the background material :-)

 - Erik

[Philipp Wollermann]

Let’s. Just. Do. The. Wonderful. Change.

This discussion just delayed the 0.18 release for over a week, as Klaus is on vacation tomorrow and on BazelCon next week. Was that worth it?

We are at version 0.x. Projects will have to update how they use bazelrc, but projects break with every new version anyway currently.

We are overloaded with work, no one owns that  area of our code and Chloe is no longer on the team. Let’s accept we screwed up here a bit, but then go on with life and let’s not create even more work for us here.

Instead let’s focus on our stability process for the future, work towards Bazel 1.0 and be done with it.

Philipp

--

[Erik Gorset]

On Thu, 4 Oct 2018 at 18:57, Philipp Wollermann <phi...@google.com> wrote:

Let’s. Just. Do. The. Wonderful. Change.

This discussion just delayed the 0.18 release for over a week, as Klaus is on vacation tomorrow and on BazelCon next week. Was that worth it?

We are at version 0.x. Projects will have to update how they use bazelrc, but projects break with every new version anyway currently.

We are overloaded with work, no one owns that  area of our code and Chloe is no longer on the team. Let’s accept we screwed up here a bit, but then go on with life and let’s not create even more work for us here.

Instead let’s focus on our stability process for the future, work towards Bazel 1.0 and be done with it.

As the one that started this discussion, I'm sorry if you don't feel it was worth it.

I do hope that the intention behind release candidates is for external users and companies to test and uncover problems before a new release is shipped. If that's the case, then I would disagree with your sentiment and say it's definitely worth it to delay the release to avoid breaking high profile projects.

I see that musiccom...@gmail.com suggested a single line fix to add back support for tools/bazel.rc - why not go with that?

 - Erik

[Tony Aiuto]

I agree with Erik. Delay the release. Instead of the fatal warning:

WARNING: The following rc files are no longer being read, please transfer their contents or import their path into one of the standard rc files:

/tmp/grpc/tools/bazel.rc

Make it 

WARNING: The following rc files will no longer be read in Bazel 0.19, please transfer their contents or import their path into one of the standard rc files

and make sure the behavor is that we read from the first one we find, so people can move it while still using 0.18.

I know I am in the minority when I advocate for printing deprecation warnings on stdout, but this is absolutely one time where that is the right thing to do. It is a user actionable warning and we will be telling them the migration window.

--

You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAOv6%2B8TQr4TKNz%2BnaKOwPW2rFz1CzuVpewh7RiLQTpHH%2BG3n7w%40mail.gmail.com.

[Laurent Le Brun]

> This discussion just delayed the 0.18 release for over a week, as Klaus is on vacation tomorrow and on BazelCon next week. Was that worth it?

Definitely.

Erik did the right thing by reporting the problem. We didn't handle the feedback correctly and the discussion took too much time. There's a lesson to learn: we need to improve the way we deal with user reports during release candidates. I think this is very important, and we need a good workflow before we can have 1.0.

So it's worth it because it gives us experience, and a change to improve our workflow. We have to think about it and make sure it won't happen again.

--

Laurent

[Philipp Wollermann]

> I see that musiccom...@gmail.com suggested a single line fix to add back support for tools/bazel.rc - why not go with that?

Because that single line fix would break our tests.

[Philipp Wollermann]

Tony, Laurent,

I tried to turn musiccom...@gmail.com's proposed temporary workaround into a CL that passes our tests (//src/test/cpp:rc_file_test is the relevant one) and doesn't introduce other problems. Unfortunately, I didn't succeed. Sorry :(

As you seem to care deeply about this and because there's otherwise no clear owner for this, would you mind taking this into your hands and send me or some other suitable reviewer a pull request that we can patch into 0.18 and a rollback of that immediately after (so that 0.19 will ship the new behavior)? I'll work with Klaus to get it cherry-picked and tested then.

While I'm at least somewhat familiar with C++ and I'd love to help out here, it didn't work out just now and tomorrow I really have to prepare slides for a talk at BazelCon that still need to go through our approval process, so won't be able to.

Thanks,

Philipp

[Dmitry Lomov]

I agree that we cannot release 0.18 when our new behavior directly contradicts our stated guidance on the website.

Let's delay the release and try to get it fixed if we can.

I am looking at it right now, will file appropriate bug and report progress there.

Dmitry

--

Google Germany GmbH

Erika-Mann-Straße 33, 80636 München, Germany