Release @google-cloud/bigquery v2.1.1

[callmehiphop]

This pull request was generated using releasetool.

[codecov]

Codecov Report

Merging #396 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #396   +/-   ##
=======================================
  Coverage   99.45%   99.45%           
=======================================
  Files           4        4           
  Lines         547      547           
  Branches       76       76           
=======================================
  Hits          544      544           
  Misses          2        2           
  Partials        1        1

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ba5c82e...6322cf9. Read the comment docs.

[stephenplusplus]

This is a tricky kind of fix, since the interpretation against semver isn't always a clear win for the user. This fix could be breaking change-ish for how the user has handled Jobs in the past.

Before: Job emits 'error'.
After: Job completes successfully.

We don't really know what the user does in each of those scenarios, although it seems relatively safe to fail less for the user.

So I don't know if we should bump the major for this (anyone think we should?), but at least calling it out in the docs release notes might be helpful to someone.

[callmehiphop]

You make a good point and I believe @bcoe shares a similar opinion. I would be curious to hear what others think as well. While this fix is breaking-ish, it's only because it wasn't implemented correctly to begin with. I think that implies users weren't expecting the code to behave the way it did and that a patch would be appropriate.

[bcoe]

Personally, I would lean towards calling this a breaking change:

1. if you're making an effort to adhere to semver, it's important to move away from attaching too much meaning to the major digit; changing the major just means you've made a breaking API change, it doesn't need to correlate with an exciting new release of your application.
2. @google-cloud/bigquery has enough users that I'd bet at least one of them was relying on the fact that results would populate even though an error was occurring.

[callmehiphop]

@bcoe all sounds reasonable to me! I've never had much of a say in our breaking change policies, so I would delegate to @JustinBeckwith on that one.

[callmehiphop]

FWIW I think this functionality has been broken since 2.0.4 (December) and all body errors have been ignored entirely.

[bcoe]

Let's compromise and call out the change in the CHANGELOG, as:

Note: a bug was fixed that some people may have been relying on, results were still be populated in error
responses when an API returned more than the maximum configured errors. 

I think we need to better define our policies around breaking API changes, in relation to fixes, and I don't want to block this release.

[callmehiphop]

This is going to drive some one crazy, but I'm ok trying to make a major release (assuming no one objects) and also trying to squeeze #385 in with it.

[JustinBeckwith]

SGTM. We closing this out then?

[callmehiphop]

Yar

[bcoe]

I'd vote for calling this 3.0.0, but could be convinced that it's a safe enough change that it's unlikely to disrupt our users (and need not be a major).