Skip to content

Latest commit

 

History

History
95 lines (58 loc) · 5.16 KB

RELEASING.md

File metadata and controls

95 lines (58 loc) · 5.16 KB
Raw

Releasing Google Cloud Ruby Client

These instructions apply to every gem within the Google Cloud Ruby Client project.

Each gem must be released separately. In order for the docs for the google-cloud package to build correctly, the only entry in docs/manifest.json that can be updated in the version commit preceding the release tag is the entry for the gem in the tag. The docs build will fail if you attempt to release multiple gems in parallel, since the first tag build will not yet find the listed docs for the other gems in the gh-pages branch.

The Google Cloud Ruby Client project uses semantic versioning. Replace the <prev_version> and <version> placeholders shown in the examples below with the appropriate numbers, e.g. 0.1.0 and 0.2.0. Replace the <gem> placeholder with the appropriate full name of the package, e.g. google-cloud-datastore.

After all pull requests for a release have been merged and all Circle CI builds are green, you may create a release as follows:

  1. Build the gem locally.
$ rake build
  1. Install the gem locally.
$ rake install

  1. Using IRB (not rake console!), manually test the gem that you installed in the previous step.

  2. Open the GitHub compare view in your browser.

open https://github.com/GoogleCloudPlatform/google-cloud-ruby/compare/v<prev_version>...master

  1. Review the commits in the GitHub compare view, making notes of significant changes. (For examples of what a significant change is, browse the changes in the gem's CHANGELOG.md

  2. If you haven't already, switch to the master branch, ensure that you have no changes, and pull from origin.

$ git checkout master
$ git status
$ git pull --rebase

  1. Edit the gem's CHANGELOG.md. Using your notes from the previous step, write bullet-point lists of the major and minor changes. You can also add examples, fixes, thank yous, and anything else helpful or relevant. See google-cloud-node v0.18.0 for an example with all the bells and whistles.

  2. Edit the gem's version.rb file, changing the value of VERSION to your new version number.

  3. Edit the gem's entry in docs/manifest.json, adding your new version number to the head of the list, and moving "master" to be just below it.

  4. If your version change is greater than the semver patch version, edit the requirement for the gem in google-cloud/google-cloud.gemspec, replacing the old version number for the gem with your new version number.

  5. Commit your changes. Copy and paste the significant points from your CHANGELOG.md edit as the description in your commit message.

$ git commit -am "Release <gem> <version> ..."
  1. Ensure again that you have every commit from origin master.
$ git pull --rebase
  1. Tag the version.
$ git tag -m '<gem>/v<version>' <gem>/v<version>
  1. Push your commit.
$ git push
  1. Push your tag.
$ git push --tags

  1. On the google-cloud-ruby releases page, click Draft a new release. Complete the form. Include the bullet-point lists of the major and minor changes from the gem's CHANGELOG.md. You can also add examples, fixes, thank yous, and anything else helpful or relevant. See google-cloud-node v0.18.0 for an example with all the bells and whistles.

  2. Click Publish release.

  3. Check that the Circle CI build has passed for the tag. Also, inspect the build logs to confirm that the release task completed successfully, and that the docs build succeeded. This can fail on a green build because it is an "after" action in the build.

  4. Confirm that the gem for the new version is available on RubyGems.org.

  5. Confirm that the new version is displayed after "Latest release" on the google-cloud-ruby gh-pages site.

  6. Confirm that the new version is displayed in the packages pulldown and the version switcher on the google-cloud-ruby docs site. Verify that the new docs version contains the public API changes in the release.

  7. Some time later, after they have completed, confirm that Travis CI (Mac OS X) and Appveyor CI (Windows) builds are also green.

  8. If your version change is greater than the semver patch version, then when you are done releasing all individual packages, you should follow these same instructions to release the google-cloud umbrella package.

High fives all around!