This removes some steps from the release process. These two locations
aren't special enough in way that deserves manually changing the version
each release.
Full end to end implementation of gRPC server as a Servlet including tests and examples
Co-authored-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Co-authored-by: Chengyuan Zhang <chengyuanzhang@google.com>
CentOS 6 is dead and no longer has update servers. CentOS 7 is older
than Debian 9 (oldstable), so binaries hopefully work on both. More
testing is necessary, but everything's broken now, so this is better
than nothing.
We stop using protoc-artifacts because now the container is
straight-forward enough that we can just use our own. Previously the
"devtoolset" stuff made us want to share the container.
* cronet: update README for using published grpc-cronet with play service Cronet implementation.
* doc: Added cronet/README.md version update to RELEASING.md.
For security, we should change http into https links.
Co-Authored-By: Nguyen Van Trung [trungnvfet@outlook.com](mailto:trungnvfet@outlook.com)
Signed-off-by: Nguyen Quang Huy [huynq0911@gmail.com](mailto:huynq0911@gmail.com)
This greatly reduces the amount of content. The removed content was
already deteriorating. For example, it references grpc-java-deploy which
is no longer present nor necessary. It also didn't suggest using
build_docker.sh for building protoc-artifacts.
While the docs could have been updated, without actually running them
they are unlikely to be functional. Removing the docs seems better than
spending effort of maintaining them, especially since they add confusion
to the process and are a scary amount of content for new devs.
The steps are still valid, and should be considered the source of
truth. However, these steps have been automated as a kokoro job. Add a
link to the documentation for the kokoro job.
If the release branch (i.e., v1.11.x) was not up-to-date with the local
repo, then the push to update the branch will fail. Doing it first
allows you to notice, merge in the updates and fix the tag before
pushing it.
Also document pulling the most up-to-date version of the release branch
before creating the 'release' branch. That would reduce the amount of
time the release branch could be modified.
Terry Wilson