@@ -79,14 +79,14 @@ here is how to manually cut a release of `cloud.google.com/go`.
79
79
[ continuous Kokoro build] ( http://go/google-cloud-go-continuous ) . If there are
80
80
any failures in the most recent build, address them before proceeding with
81
81
the release.
82
- 1 . Navigate to ` google-cloud-go/ ` and switch to master .
82
+ 1 . Navigate to ` google-cloud-go/ ` and switch to main .
83
83
1 . ` git pull `
84
84
1 . Run ` git tag -l | grep -v beta | grep -v alpha ` to see all existing releases.
85
85
The current latest tag ` $CV ` is the largest tag. It should look something
86
86
like ` vX.Y.Z ` (note: ignore all ` LIB/vX.Y.Z ` tags - these are tags for a
87
87
specific library, not the module root). We'll call the current version ` $CV `
88
88
and the new version ` $NV ` .
89
- 1 . On master , run ` git log $CV... ` to list all the changes since the last
89
+ 1 . On main , run ` git log $CV... ` to list all the changes since the last
90
90
release. NOTE: You must manually visually parse out changes to submodules [ 1]
91
91
(the ` git log ` is going to show you things in submodules, which are not going
92
92
to be part of your release).
@@ -98,7 +98,7 @@ here is how to manually cut a release of `cloud.google.com/go`.
98
98
and create a PR titled ` chore: release $NV ` .
99
99
1 . Wait for the PR to be reviewed and merged. Once it's merged, and without
100
100
merging any other PRs in the meantime:
101
- a. Switch to master .
101
+ a. Switch to main .
102
102
b. ` git pull `
103
103
c. Tag the repo with the next version: ` git tag $NV ` .
104
104
d. Push the tag to origin:
@@ -118,21 +118,21 @@ here is how to manually cut a release of a submodule.
118
118
any failures in the most recent build, address them before proceeding with
119
119
the release. (This applies even if the failures are in a different submodule
120
120
from the one being released.)
121
- 1 . Navigate to ` google-cloud-go/ ` and switch to master .
121
+ 1 . Navigate to ` google-cloud-go/ ` and switch to main .
122
122
1 . ` git pull `
123
123
1 . Run ` git tag -l | grep datastore | grep -v beta | grep -v alpha ` to see all
124
124
existing releases. The current latest tag ` $CV ` is the largest tag. It
125
125
should look something like ` datastore/vX.Y.Z ` . We'll call the current version
126
126
` $CV ` and the new version ` $NV ` .
127
- 1 . On master , run ` git log $CV.. -- datastore/ ` to list all the changes to the
127
+ 1 . On main , run ` git log $CV.. -- datastore/ ` to list all the changes to the
128
128
submodule directory since the last release.
129
129
1 . Edit ` datastore/CHANGES.md ` to include a summary of the changes.
130
130
1 . In ` internal/version ` run ` go generate ` .
131
131
1 . Commit the changes, ignoring the generated ` .go-r ` file. Push to your fork,
132
132
and create a PR titled ` chore(datastore): release $NV ` .
133
133
1 . Wait for the PR to be reviewed and merged. Once it's merged, and without
134
134
merging any other PRs in the meantime:
135
- a. Switch to master .
135
+ a. Switch to main .
136
136
b. ` git pull `
137
137
c. Tag the repo with the next version: ` git tag $NV ` .
138
138
d. Push the tag to origin:
0 commit comments