You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixing release script bugs, making formal releases manual (#1590)
* Not auto-releasing after close (so that releases can be staged)
* Splitting release.sh into stage_release.sh and finalize_release.sh
* Stripping the qualifier from the SITE_VERSION for generating the gh-pages site
* Fixing deploy.sh (the input checking was wrong)
* Not running any tests in deploy.sh (they are already run in other contexts
before this point)
* Updating RELEASING.md with the new process
Copy file name to clipboardExpand all lines: RELEASING.md
+17-10Lines changed: 17 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,18 +1,25 @@
1
1
### Overview
2
2
3
-
Most of the release process is handled by the `after_success.sh` script, triggered after Travis CI successfully completes a non-PR build. A new artifact will be released to Maven Central Repository via Travis CI when "-SNAPSHOT" is not included in the version (as listed in the base directory's `pom.xml`). The website and README files will also be updated automatically in this case. When "-SNAPSHOT" is included in the version, Travis only updates the artifact in the snapshot repository.
3
+
The release process for SNAPSHOT versions is handled by the `after_success.sh` script, triggered after Travis CI successfully completes a non-PR build. A new SNAPSHOT artifact will be released to the snapshot repository as part of this script.
4
4
5
5
### To push a release version
6
6
7
-
1. Run `utilities/update_pom_version.sh` from the repository's base directory.
8
-
This script takes an optional argument denoting the new version. By default, if the current version is X.Y.Z-SNAPSHOT, the script will update the version in all the pom.xml files to X.Y.Z. If desired, another version can be supplied via command line argument instead.
7
+
1. Make sure the team agrees that it is time to release. Verify that all unit and integration tests for the last commit have passed.
9
8
10
-
2.Create a PR to update the pom.xml version. If releasing a new client library, this PR should also update javadoc grouping in the base directory's [pom.xml](./pom.xml).
11
-
PRs that don't release new modules should look something like [#225](https://github.com/GoogleCloudPlatform/google-cloud-java/pull/225). PRs that do release a new module should also add the appropriate packages to the javadoc groups "SPI" and "Test helpers", as shown in [#802](https://github.com/GoogleCloudPlatform/google-cloud-java/pull/802) for `google-cloud-dns`. After this PR is merged into GoogleCloudPlatform/google-cloud-java, Travis CI will push a new website to GoogleCloudPlatform/gh-pages, push a new artifact to the Maven Central Repository, and update versions in the README files. Do not merge in any non-release-related pull requests between the start of step 2 and the end of step 6. Between these steps, the project version is a non-snapshot version, so any commits to the master branch will cause Travis to spend extra resources attempting to redeploy artifacts.
9
+
2.Run `utilities/update_pom_version.sh` from the repository's base directory.
10
+
This script takes an optional argument denoting the new version. By default, if the current version is X.Y.Z-SNAPSHOT, the script will update the version in all the pom.xml files to X.Y.Z. If desired, another version can be supplied via command line argument instead. Commit this version locally:
12
11
13
-
3. Before moving on, verify that the artifacts have successfully been pushed to the Maven Central Repository. Open Travis CI, click the ["Build History" tab](https://travis-ci.org/GoogleCloudPlatform/google-cloud-java/builds), and open the second build's logs for Step 2's PR. Be sure that you are not opening the "Pull Request" build logs. When the build finishes, scroll to the end of the log and verify that the artifacts were successfully staged and deployed. Search for `google-cloud` on the [Sonatype website](https://oss.sonatype.org/#nexus-search;quick~google-cloud) and check the latest version number. In rare cases (when the Maven plugin that determines the version of the repository fails), the artifacts may not be deployed even if the version in the pom.xml files doesn't contain `SNAPSHOT`. If the artifacts weren't deployed due to invalid version parsing or a flaky test, rerun the build.
12
+
```
13
+
git commit -m "Release [VERSION HERE]"
14
+
```
15
+
16
+
3. Run `utilities/stage_release.sh`.
17
+
This script builds and stages the release artifact on the Maven Central Repository, updates the README.md files with the release version + commits them locally, and finally generates a new site version for the gh-pages branch under a temporary directory named `tmp_gh-pages`. If you haven't run the release process before, it's worth verifying everything; check the staged release on the Sonatype website, and verify that the local commits have the right version updates.
18
+
19
+
4. Run `utilities/finalize_release.sh`.
20
+
This script will release the staged artifact on the Maven Central Repository and push the README.md and gh-pages updates to github.
14
21
15
-
4. Publish a release on Github manually.
22
+
5. Publish a release on Github manually.
16
23
Go to the [releases page](https://github.com/GoogleCloudPlatform/google-cloud-java/releases) and open the appropriate release draft. Make sure the "Tag Version" is `vX.Y.Z` and the "Release Title" is `X.Y.Z`, where `X.Y.Z` is the release version as listed in the `pom.xml` files. The draft should already have all changes that impact users since the previous release. To double check this, you can use the `git log` command and look through the merged master branch pull requests. Here is an example of the log command to get non-merge commits between v0.0.12 and v0.1.0:
17
24
18
25
```
@@ -21,12 +28,12 @@ Go to the [releases page](https://github.com/GoogleCloudPlatform/google-cloud-ja
21
28
22
29
Ensure that the format is consistent with previous releases (for an example, see the [0.1.0 release](https://github.com/GoogleCloudPlatform/google-cloud-java/releases/tag/v0.1.0)). After adding any missing updates and reformatting as necessary, publish the draft. Finally, create a new draft for the next release.
23
30
24
-
5. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version).
31
+
6. Run `utilities/update_pom_version.sh` again (to include "-SNAPSHOT" in the project version).
25
32
As mentioned before, there is an optional version argument. By default, the script will update the version from "X.Y.Z" to "X.Y.Z+1-SNAPSHOT". Suppose a different version is desired, for example X+1.0.0-SNAPSHOT. Then the appropriate command to run would be `utilities/update_pom_version.sh X+1.0.0-SNAPSHOT`.
26
33
27
-
6. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/google-cloud-java/pull/227).
34
+
7. Create and merge in another PR to reflect the updated project version. For an example of what this PR should look like, see [#227](https://github.com/GoogleCloudPlatform/google-cloud-java/pull/227).
28
35
29
-
7. Be sure to update Google Cloud Platform docs, [java-docs-samples](https://github.com/GoogleCloudPlatform/java-docs-samples) code/docs, and [getting-started-java](https://github.com/GoogleCloudPlatform/getting-started-java) code/docs. See directions [here](https://docs.google.com/a/google.com/document/d/1SS3xNn2v0qW7EadGUPBUAPIQAH5VY6WSFmT17ZjjUVE/).
36
+
8. Be sure to update Google Cloud Platform docs, [java-docs-samples](https://github.com/GoogleCloudPlatform/java-docs-samples) code/docs, and [getting-started-java](https://github.com/GoogleCloudPlatform/getting-started-java) code/docs. See directions [here](https://docs.google.com/a/google.com/document/d/1SS3xNn2v0qW7EadGUPBUAPIQAH5VY6WSFmT17ZjjUVE/).
0 commit comments