blob: 6adaeb182bb20da9052e05f35d9da60968a1eb2b [file] [log] [blame] [view]
nmittler483738e2015-06-08 14:32:37 -07001How to Create a Release of GRPC Java (for Maintainers Only)
2===============================================================
3
4Build Environments
5------------------
6We deploy GRPC to Maven Central under the following systems:
7- Ubuntu 14.04 with Docker 1.6.1 that runs CentOS 6.6
8- Windows 7 64-bit with MSYS2 with mingw32 and mingw64
9- Mac OS X 10.9.5
10
11Other systems may also work, but we haven't verified them.
12
13Prerequisites
14-------------
15
16### Setup OSSRH and Signing
17
18If you haven't deployed artifacts to Maven Central before, you need to setup
19your OSSRH (OSS Repository Hosting) account and signing keys.
20- Follow the instructions on [this
21 page](http://central.sonatype.org/pages/ossrh-guide.html) to set up an
22 account with OSSRH.
23- (For release deployment only) Install GnuPG and [generate your key
24 pair](https://www.gnupg.org/documentation/howtos.html). You'll also
25 need to [publish your public key](https://www.gnupg.org/gph/en/manual.html#AEN464)
26 to make it visible to the Sonatype servers
27 (e.g. `gpg --keyserver pgp.mit.edu --send-key <key ID>`).
28- Put your GnuPG key password and OSSRH account information in
29 `<your-home-directory>/.gradle/gradle.properties`.
30
31```
32# You need the signing properties only if you are making release deployment
33signing.keyId=<8-character-public-key-id>
34signing.password=<key-password>
35signing.secretKeyRingFile=<your-home-directory>/.gnupg/secring.gpg
36
37ossrhUsername=<ossrh-username>
38ossrhPassword=<ossrh-password>
39checkstyle.ignoreFailures=false
40```
41
42### Build Protobuf
43Protobuf libraries are needed for compiling the GRPC codegen. Despite that you
44may have installed Protobuf on your system, you may want to build Protobuf
45separately and install it under your personal directory, because
46
471. The Protobuf version installed on your system may be different from what
48 GRPC requires. You may not want to pollute your system installation.
492. We will deploy both 32-bit and 64-bit versions of the codegen, thus require
50 both variants of Protobuf libraries. You don't want to mix them in your
51 system paths.
52
53Please see the [Main Readme](README.md) for details on building protobuf.
54
55Tagging the Release
56----------------------
57The first step in the release process is to create a release branch and then
58from it, create a tag for the release. Our release branches follow the naming
59convention of `v<major>.<minor>.x`, while the tags include the patch version
60`v<major>.<minor>.<patch>`. For example, the same branch `v0.7.x`
61would be used to create all `v0.7` tags (e.g. `v0.7.0`, `v0.7.1`).
62
631. Create the release branch:
64
65 ```bash
66 $ git checkout -b v<major>.<minor>.x master
67 ```
682. Next, increment the version in `build.gradle` in `master` to the next
69 minor snapshot (e.g. ``0.8.0-SNAPSHOT``).
703. In the release branch, change the `build.gradle` to the next release version
71 (e.g. `0.7.0`)
724. Push the release branch to github
73
74 ```bash
75 $ git push upstream v<major>.<minor>.x
76 ```
775. In the release branch, create the release tag using the `Major.Minor.Patch`
78 naming convention:
79
80 ```bash
81 $ git tag -a v<major>.<minor>.<patch>
82 ```
836. Push the release tag to github:
84
85 ```bash
86 $ git push upstream v<major>.<minor>.<patch>
87 ```
887. Update the `build.gradle` in the release branch to point to the next patch
89 snapshot (e.g. `0.7.1-SNAPSHOT`).
908. Push the updated release branch to github.
91
92 ```bash
93 $ git push upstream v<major>.<minor>.x
94 ```
95
96Setup Build Environment
97---------------------------
98
99### Linux
100The deployment for Linux uses [Docker](https://www.docker.com/) running
101CentOS 6.6 in order to ensure that we have a consistent deployment environment
102on Linux. You'll first need to install Docker if not already installed on your
103system.
104
1051. Under the [Protobuf source directory](https://github.com/google/protobuf),
106 build the `protoc-artifacts` image:
107
108 ```bash
109 protobuf$ docker build -t protoc-artifacts protoc-artifacts
110 ```
1112. Under the grpc-java source directory, build the `grpc-java-deploy` image:
112
113 ```bash
114 grpc-java$ docker build -t grpc-java-deploy compiler
115 ```
1163. Start a Docker container that has the deploy environment set up for you. The
117 GRPC source is cloned into `/grpc-java`.
118
119 ```bash
120 $ docker run -it --rm=true grpc-java-deploy
121 ```
122
123 Note that the container will be deleted after you exit. Any changes you have
124 made (e.g., copied configuration files) will be lost. If you want to keep the
125 container, remove `--rm=true` from the command line.
1264. Next, you'll need to copy your OSSRH credentials and GnuPG keys to your docker container.
127 Run `ifconfig` in the host, find the IP address of the `docker0` interface.
128 Then in Docker:
129
130 ```bash
131 $ scp -r <your-host-user>@<docker0-IP>:./.gnupg ~/
132 $ mkdir ~/.gradle
133 $ scp -r <your-host-user>@<docker0-IP>:./.gradle/gradle.properties ~/.gradle
134 ```
135
136 You'll also need to update `signing.secretKeyRingFile` in
137 `/root/.gradle/gradle.properties` to point to `/root/.gnupg/secring.gpg`.
138
139### Windows
140
141#### Windows 64-bit with MSYS2 (Recommended for Windows)
142Because the gcc shipped with MSYS2 doesn't support multilib, you have to
143compile and deploy 32-bit and 64-bit binaries in separate steps.
144
145##### Under MinGW-w64 Win32 Shell
1461. Compile and install 32-bit protobuf:
147
148 ```bash
149 protobuf$ ./configure --disable-shared --prefix=$HOME/protobuf-32
150 protobuf$ make clean && make && make install
151 ```
1522. Configure CXXFLAGS needed by the protoc plugin when building.
153
154 ```bash
155 grpc-java$ export CXXFLAGS="-I$HOME/protobuf-32/include" \
156 LDFLAGS="-L$HOME/protobuf-32/lib"
157 ```
158
159##### Under MinGW-w64 Win64 Shell
1601. Compile and install 64-bit protobuf:
161
162 ```bash
163 protobuf$ ./configure --disable-shared --prefix=$HOME/protobuf-64
164 protobuf$ make clean && make && make install
165 ```
1662. Configure CXXFLAGS needed by the protoc plugin when building.
167
168 ```bash
169 grpc-java$ export CXXFLAGS="-I$HOME/protobuf-64/include" \
170 LDFLAGS="-L$HOME/protobuf-64/lib"
171 ```
172
173#### Windows 64-bit with Cygwin64 (TODO: incomplete)
174Because the MinGW gcc shipped with Cygwin64 doesn't support multilib, you have
175to compile and deploy 32-bit and 64-bit binaries in separate steps.
176
1771. Compile and install 32-bit protobuf. `-static-libgcc -static-libstdc++` are
178 needed for `protoc` to be successfully run in the unit test.
179
180 ```bash
181 protobuf$ LDFLAGS="-static-libgcc -static-libstdc++" ./configure --host=i686-w64-mingw32 --disable-shared --prefix=$HOME/protobuf-32
182 protobuf$ make clean && make && make install
183 ```
184
1852. Compile and install 64-bit protobuf:
186
187 ```bash
188 protobuf$ ./configure --host=x86_64-w64-mingw32 --disable-shared --prefix=$HOME/protobuf-64
189 protobuf$ make clean && make && make install
190 ```
191
192### Mac
193Please refer to [Protobuf
194README](https://github.com/google/protobuf/blob/master/README.md) for how to
195set up GCC and Unix tools on Mac.
196
197Mac OS X has been 64-bit-only since 10.7 and we are compiling for 10.7 and up.
198We only build 64-bit artifact for Mac.
199
2001. Compile and install protobuf:
201
202 ```bash
203 protobuf$ CXXFLAGS="-m64" ./configure --disable-shared --prefix=$HOME/protobuf
204 protobuf$ make clean && make && make install
205 ```
2062. Configure CXXFLAGS needed by the protoc plugin when building.
207
208 ```bash
209 grpc-java$ export CXXFLAGS="-I$HOME/protobuf/include" \
210 LDFLAGS="$HOME/protobuf/lib/libprotobuf.a $HOME/protobuf/lib/libprotoc.a"
211 ```
212
213Build and Deploy
214----------------
215We currently distribute the following OSes and architectures:
216
217| OS | x86_32 | x86_64 |
218| --- | --- | --- |
219| Linux | X | X |
220| Windows | X | X |
221| Mac | | X |
222
223Deployment to Maven Central (or the snapshot repo) is a two-step process. The only
224artifact that is platform-specific is codegen, so we only need to deploy the other
225jars once. So the first deployment is for all of the artifacts from one of the selected
226OS/architectures. After that, we then deploy the codegen artifacts for the remaining
227OS/architectures.
228
229**NOTE: _Before building/deploying, be sure to switch to the appropriate branch or tag in
230the grpc-java source directory._**
231
232### First Deployment
233
234As stated above, this only needs to be done once for one of the selected OS/architectures.
235The following command will build the whole project and upload it to Maven
236Central.
237```bash
238grpc-java$ ./gradlew clean build && ./gradlew uploadArchives
239```
240
241If the version has the `-SNAPSHOT` suffix, the artifacts will automatically
242go to the snapshot repository. Otherwise it's a release deployment and the
243artifacts will go to a freshly created staging repository.
244
245### Deploy GRPC Codegen for Additional Platforms
246The previous step will only deploy the codegen artifacts for the OS you run on
247it and the architecture of your JVM. For a fully fledged deployment, you will
248need to deploy the codegen for all other supported OSes and architectures.
249
250To deploy the codegen for an OS and architecture, you must run the following
251commands on that OS and specify the architecture by the flag `-PtargetArch=<arch>`.
252
253If you are doing a snapshot deployment:
254
255```bash
256grpc-java$ ./gradlew clean grpc-compiler:build grpc-compiler:uploadArchives -PtargetArch=<arch>
257```
258
259When deploying a Release, the first deployment will create
260[a new staging repository](https://oss.sonatype.org/#stagingRepositories). You'll need
261to look up the ID in the OSSRH UI (usually in the form of `iogrpc-*`). Codegen
262deployment commands should include `-PrepositoryId=<repository-id>` in order to
263ensure that the artifacts are pushed to the same staging repository.
264
265```bash
266grpc-java$ ./gradlew clean grpc-compiler:build grpc-compiler:uploadArchives -PtargetArch=<arch> \
267 -PrepositoryId=<repository-id>
268```
269
270Releasing on Maven Central
271--------------------------
272Once all of the artifacts have been pushed to the staging repository, the
273repository must first be `closed`, which will trigger several sanity checks
274on the repository. If this completes successfully, the repository can then
275be `released`, which will begin the process of pushing the new artifacts to
276Maven Central (the staging repository will be destroyed in the process). You can
277see the complete process for releasing to Maven Central on the [OSSRH site]
278(http://central.sonatype.org/pages/releasing-the-deployment.html).
279
280Notify the Community
281--------------------
282After waiting ~1 day and verifying that the release appears on [Maven Central]
283(http://mvnrepository.com/), the last step is to document and publicize the release.
284
2851. Add [Release Notes](https://github.com/grpc/grpc-java/releases) for the new tag.
286 The description should include any major fixes or features since the last release.
287 You may choose to add links to bugs, PRs, or commits if appropriate.
2882. Post a release announcement to [grpc-io](https://groups.google.com/forum/#!forum/grpc-io)
289 (`grpc-io@googlegroups.com`). The title should be something that clearly identifies
290 the release (e.g.`GRPC-Java <tag> Released`).