Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: update release instructions #3280

Merged
merged 1 commit into from
Jul 20, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
65 changes: 20 additions & 45 deletions internal/docs/release.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,29 +2,16 @@

To do a release:

- Announce to the team that a release is in progress - avoid merging PRs
during the release window (likely 1-2 hours). TODO(eliben): find a way to
enforce this on GitHub.

- Make sure all tests pass locally with `runchecks.sh` and the build is
green.

- Run the prerelease checks until everything is passing.

- Create a new branch (`git checkout -B prerelease`). Running the script
will modify hundreds of golden files, so you want to do it in a branch.
You can delete the branch and abandon all the changes when you are done.
- Run `./internal/testing/prerelease.sh init` until it finishes with
`SUCCESS`. Note that there are some known failures that are logged but
don't prevent overall `SUCCESS`.
- Run `./internal/testing/prerelease.sh run`. Again, there are some known
failures. You can re-run any unexpected failures independently to
investigate; see the `prerelease.sh` script to see the exact command
line to use.
- Run `./internal/testing/prerelease.sh cleanup` when you are done.
- Delete the branch (`-D` to force deleting with uncommitted changes).

- Create a new branch for the release (`git checkout -B release`).
- Pick the new release name; it's probably `v0.x.0` where `x` is whatever the
[last release](https://github.com/google/go-cloud/releases/latest) was plus
one, but follow [semantic versioning](https://semver.org/).

- Consider updating dependencies via `internal/testing/update_deps.sh` if it
hasn't been done recently. Do this as a separte step before the release.

- Create a new branch for the release (`git checkout -B prerelease`).

- Update the `User-Agent` version in internal/useragent/useragent.go.

- Run the release helper tool to remove `replace` lines from the `go.mod`
files of submodules:
Expand All @@ -33,32 +20,27 @@ To do a release:
$ go run internal/releasehelper/releasehelper.go dropreplace
```

Check that everything looks in order (with `git diff`) and commit.

- Pick the new release name; it's probably `v0.x.0` where `x` is whatever the
[last release](https://github.com/google/go-cloud/releases/latest) was plus
one, but follow [semantic versioning](https://semver.org/).

- Run the release helper tool to set the version in `require` directives of
submodules to the new (yet unreleased) version:

```bash
$ go run internal/releasehelper/releasehelper.go setversion v0.x.0
```

Check that everything looks in order (with `git diff`) and commit.
- Commit and create a PR. Tests will fail for this PR because submodules depend on a
version of the main module that wasn't tagged yet, so you may have to
force-merge the PR. Note that this does not affect users, since a new
version hasn't been tagged yet.

- Create a PR. Tests will fail for this PR because submodules depend on a
version of the main module that wasn't tagged yet. Enable force merging in
GitHub settings and force-merge the PR. Note that this does not affect
users, since a new version hasn't been tagged yet.
- `git sync` your local client and move to the master branch.

- Tag new versions for all modules marked to be released (`yes` in the `released` column)
in the `./allmodules` file with `./internal/testing/git_tag_modules.sh v0.X.0`.
- Tag new versions by running `./internal/testing/git_tag_modules.sh v0.X.0`.

- Push tags to upstream with `git push upstream --tags`

- Compile release notes by reviewing the commits since the last release (use
- Go to [Releases](https://github.com/google/go-cloud/releases). Click `Draft
a new release`, enter your release name, select your tag from the dropdown,
and enter release notes by reviewing the commits since the last release (use
the [Compare](https://github.com/google/go-cloud/compare/v0.1.1...v0.2.0)
page for this).

Expand All @@ -68,15 +50,11 @@ To do a release:
- List highlights in the form: `**<component>**: <description of change,
past tense>`. For example, `**blob**: Added feature foo.`.

- Go to [Releases](https://github.com/google/go-cloud/releases). Click `Draft
a new release`, enter your release name, select your tag from the dropdown,
and enter your release notes.

- Send an email to
[[email protected]](https://groups.google.com/forum/#!forum/go-cloud)
announcing the release, and including the release notes.

- Disable force pushing on GitHub.
- Create a new branch for the postrelease (`git checkout -B postrelease`).

- Add back `replace` lines:

Expand All @@ -85,6 +63,3 @@ To do a release:
```

Run tests and send out a PR as usual.

- Update dependencies by running `internal/testing/update_deps.sh`, run tests
and send out a PR.
102 changes: 0 additions & 102 deletions internal/testing/check_api_change.sh

This file was deleted.

175 changes: 0 additions & 175 deletions internal/testing/prerelease.sh

This file was deleted.

Loading
Loading