GOBIN
directory (by default $(go env GOPATH)/bin
) is in your PATH
.go version
./usr/local/go
, is on your PATH
.Sign one of the contributor license agreements below.
Clone the repo: git clone https://github.com/googleapis/google-cloud-go
Change into the checked out source: cd google-cloud-go
Fork the repo and add your fork as a secondary remote (this is necessary in order to create PRs).
The Go client libraries have several modules. Each module does not strictly correspond to a single library - they correspond to trees of directories. If a file needs to be released, you must release the closest ancestor module.
To see all modules:
$ cat `find . -name go.mod` | grep module module cloud.google.com/go module cloud.google.com/go/bigtable module cloud.google.com/go/firestore module cloud.google.com/go/bigquery module cloud.google.com/go/storage module cloud.google.com/go/datastore module cloud.google.com/go/pubsub module cloud.google.com/go/spanner module cloud.google.com/go/logging
The cloud.google.com/go
is the repository root module. Each other module is a submodule.
So, if you need to release a change in bigtable/bttest/inmem.go
, the closest ancestor module is cloud.google.com/go/bigtable
- so you should release a new version of the cloud.google.com/go/bigtable
submodule.
If you need to release a change in asset/apiv1/asset_client.go
, the closest ancestor module is cloud.google.com/go
- so you should release a new version of the cloud.google.com/go
repository root module. Note: releasing cloud.google.com/go
has no impact on any of the submodules, and vice-versa. They are released entirely independently.
If there are any test failures in the Kokoro build, releases are blocked until the failures have been resolved.
cloud.google.com/go
Check for failures in the continuous Kokoro build. If there are any failures in the most recent build, address them before proceeding with the release.
If there are changes that have not yet been released a pull request should be automatically opened by release-please with a title like “chore: release 0.XX.0”, where XX is the next version to be released. To cut a release, approve and merge this pull request. Doing so will update the CHANGES.md
, tag the merged commit with the appropriate version, and draft a GitHub release.
If for whatever reason the automated release process is not working as expected, here is how to manually cut a release.
google-cloud-go/
and switch to master.git pull
git tag -l | grep -v beta | grep -v alpha
to see all existing releases. The current latest tag $CV
is the largest tag. It should look something like vX.Y.Z
(note: ignore all LIB/vX.Y.Z
tags - these are tags for a specific library, not the module root). We'll call the current version $CV
and the new version $NV
.git log $CV...
to list all the changes since the last release. NOTE: You must manually visually parse out changes to submodules [1] (the git log
is going to show you things in submodules, which are not going to be part of your release).CHANGES.md
to include a summary of the changes.internal/version/version.go
, update const Repo
to today's date with the format YYYYMMDD
.internal/version
run go generate
..go-r
file. Push to your fork, and create a PR titled chore: release $NV
.git pull
c. Tag the repo with the next version: git tag $NV
. d. Push the tag to origin: git push origin $NV
CHANGES.md
.We have several submodules, including cloud.google.com/go/logging
, cloud.google.com/go/datastore
, and so on.
To release a submodule:
(these instructions assume we're releasing cloud.google.com/go/datastore
- adjust accordingly)
google-cloud-go/
and switch to master.git pull
git tag -l | grep datastore | grep -v beta | grep -v alpha
to see all existing releases. The current latest tag $CV
is the largest tag. It should look something like datastore/vX.Y.Z
. We'll call the current version $CV
and the new version $NV
.git log $CV.. -- datastore/
to list all the changes to the submodule directory since the last release.datastore/CHANGES.md
to include a summary of the changes.internal/version
run go generate
..go-r
file. Push to your fork, and create a PR titled chore(datastore): release $NV
.git pull
c. Tag the repo with the next version: git tag $NV
. d. Push the tag to origin: git push origin $NV
datastore/CHANGES.md
.1: This should get better as submodule tooling matures.