Protobuf runtime 3.0.2 is included transitively via grpc-protobuf
v1.0.3. Protoc doesn't have to match the version identically, but must
not be newer than the runtime. We must wait until v1.1 release of grpc
to bump protobuf version in the readme.
Fixes#2578
Also removed warnings about protoc version matching runtime, since this
is no longer supposed to be a problem (starting with 3.0.0-beta-4) and
all our tests ran fine when using protoc 3.0.2 with protobuf runtime
3.1.0.
Fixes#2316
protoc no longer builds in 3.0.0 because auto-download of the gmock zip
now fails. 3.0.2 has a fix to autogen:
bba446bbf2
All that was strictly necessary was to update .travis.yml and
buildscripts/, but it helps our sanity to keep the rest of the protobuf
versions in sync. Lite is left on its existing version, because it did
not see a bump of neither the java library nor the protoc plugin.
Using grpc-all pulls in more dependencies than necessary, as virtually
no user needs both OkHttp and Netty or both Protobuf and Protobuf Nano.
When the separate deps are listed, users are much more likely to remove
unnecessary deps.
Fixes#1597
This improves our documentation for the gradle protobuf plugin, as its
version is dependent on the gradle version.
Gradle now has the --tests flag, performance improvements, and support
for OpenPGP subkeys.
We've been using 0.7.0 since 5df6ab0 and 0.7.4 since d3d253e, but hadn't
updated the README. 0.6.1 wouldn't work in Java 7, so using a newer
version can prevent users from hitting that bump.
The version of protoc to use was bumped prematurely in e2ed2e8, so it is
reverted back to beta-1 here. When 0.13.0 is released then the protoc
version should be bumped.
The compilation instructions are long and scary, and they distract from
other documentation in the README. Most users don't need them, so by
moving the instructions out we improve the ease of use of the document.
- The version of protoc should be the same as the version of
protobuf-java that is transitively depended by grpc
- Updated protobuf-gradle-plugin example to use version 0.5.0
Other classes are already following the convention that ClientFoo for
client-side, and ServerFoo for server-side. Call has been the black
sheep of the family.
- Call -> ClientCall
- Calls -> ClientCalls
- ForwardingCall* -> ForwardingClientCall*
"Interoperability" is a more appropriate name for the tests, since they
are used for testing across different implementations. They will do a
bit of integration testing, like for auth, but this is a smaller scale.
It seems the other languages (Go, C++, Node, PHP, Python, Ruby) are
using "interop" to describe the tests, and the test case specifications
document is named with "interop". After this change, C# will be the only
language calling them "integration" tests.
This change just renames the folder and artifact. We can change the
internal package names later. However, once we do a release, old
artifact names will live forever in Maven Central.
Carl Mastrangelo