Skip to content

Latest commit

 

History

History
104 lines (64 loc) · 6.25 KB

RELEASING.md

File metadata and controls

104 lines (64 loc) · 6.25 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

  2. Install the gem locally.

    $ rake install

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

  4. Review the changes since the last release.

    $ bundle exec rake changes[<gem>]

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

  6. 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 <remote> master --rebase

  7. 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.

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

  9. 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.

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

  11. Test all the version dependencies are correct.

    $ bundle update
$ bundle exec rake ci[yes]

  12. 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> ..."

  13. Ensure again that you have every commit from origin master.

    $ git pull <remote> master --rebase

  14. Tag the version.

    $ git tag <gem>/v<version>

  15. Push the tag. This will trigger a build job on Circle CI.

    $ git push <remote> <gem>/v<version>

  16. Repeat steps 1 through 15 if you're releasing multiple gems.

  17. Wait until the tag build job from step 15 has started (preferably wait for it to finish and turn green). Then push the commit to the master branch. This will trigger another Circle CI build on master branch.

    $ git push <remote> master

  18. 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.

  19. Click Publish release.

  20. Check again 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.

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

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

  23. 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.

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

  25. 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. Furthermore, if your major releases included at least one dependency of the stackdriver umbrella package (currently those dependencies are google-cloud-logging, google-cloud-trace, google-cloud-error_reporting, and google-cloud-monitoring), then you should also follow these same instructions to release the stackdriver umbrella package. It is important that the dependencies of the google-cloud and stackdriver gems remain compatible so the two can co-exist in the same bundle.

High fives all around!