diff --git a/docs/RELEASE_ISSUE_TEMPLATE.md b/docs/RELEASE_ISSUE_TEMPLATE.md index 3797746690f..9edf679c130 100644 --- a/docs/RELEASE_ISSUE_TEMPLATE.md +++ b/docs/RELEASE_ISSUE_TEMPLATE.md @@ -1,3 +1,5 @@ + + > Release Issue Template. If doing a patch release, see [here](https://github.com/ipfs/kubo/blob/master/docs/PATCH_RELEASE_TEMPLATE.md) # Items to do upon creating the release issue @@ -10,154 +12,216 @@ # Meta * Release owner: @who * Release reviewer: @who -* Expected RC date: week of 2022-MM-DD -* 🚢 Expected final release date: 2022-MM-DD +* Expected RC date: week of YYYY-MM-DD +* 🚢 Expected final release date: YYYY-MM-DD * Accompanying PR for improving the release process: (example: https://github.com/ipfs/kubo/pull/9100) See the [Kubo release process](https://pl-strflt.notion.site/Kubo-Release-Process-5a5d066264704009a28a79cff93062c4) for more info. # Kubo X.Y.Z Release -We're happy to announce Kubo X.Y.Z, bla bla... +We're happy to announce Kubo X.Y.Z! -As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will _not_ be called out in the release notes. Please make sure to update ASAP. See our [release process](https://github.com/ipfs/go-ipfs/tree/master/docs/releases.md#security-fix-policy) for details. +As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will _not_ be called out in the release notes. Please make sure to update ASAP. See our [security fix policy](https://github.com/ipfs/go-ipfs/tree/master/docs/releases.md#security-fix-policy) for details. ## 🗺 What's left for release +### Required + +### Nice to have + ## 🔦 Highlights < top highlights for this release notes. For ANY version (final or RCs) > ## ✅ Release Checklist -For each RC published in each stage: - -- version string in `version.go` has been updated (in the `release-vX.Y.Z` branch). -- new commits should be added to the `release-vX.Y.Z` branch from `master` using `git cherry-pick -x ...` - - Note: `release-` branches are protected. You can do all needed updates on a separated branch and when everything is settled push to `release-vX.Y.Z` -- tag commit with `vX.Y.Z-rcN` -- add artifacts to https://dist.ipfs.tech - 1. Make a PR against [ipfs/distributions](https://github.com/ipfs/distributions) with local changes produced by `add-version` (see [usage](https://github.com/ipfs/distributions#usage)) - 2. Wait for PR to build artifacts and generate diff (~30min) - 3. Inspect results, merge if CI is green and the diff looks ok - 4. Wait for `master` branch to build and update DNSLink at https://dist.ipfs.tech (~30min) -- cut a pre-release on [github](https://github.com/ipfs/kubo/releases) and reuse signed artifacts from https://dist.ipfs.tech/kubo (upload the result of the ipfs/distributions build in the previous step). -- Announce the RC: - - [ ] Create a new post on [IPFS Discourse](https://discuss.ipfs.tech) - - This will automatically post to IPFS Discord #ipfs-chatter - - Examples from the past: [0.14.0](https://discuss.ipfs.io/t/kubo-formerly-go-ipfs-v0-14-0-release-is-out/14794) - - [ ] Pin the topic. You need to be part of the [admin group](https://discuss.ipfs.tech/g/admins) for that. - - [ ] To the _early testers_ listed in [docs/EARLY_TESTERS.md](https://github.com/ipfs/go-ipfs/tree/master/docs/EARLY_TESTERS.md). Do this by copy/pasting their GitHub usernames and checkboxes as a comment so they get a GitHub notification. ([example](https://github.com/ipfs/go-ipfs/issues/8176#issuecomment-909356394)) - Checklist: -- [ ] **Stage 0 - Automated Testing** - - [ ] Upgrade to the latest patch release of Go that CircleCI has published +- [ ] **Stage 0 - Prerequisites** + - [ ] Open an issue against [bifrost-infra](https://github.com/protocol/bifrost-infra) ahead of the release ([example](https://github.com/protocol/bifrost-infra/issues/2109)). + - [ ] Spell out all that we want updated - gateways, the bootstraper and the cluster/preload nodes + - [ ] Mention @protocol/bifrost-team in the issue and let them know the expected date of the release + - [ ] Ensure that the `What's left for release` section has all the checkboxes checked. If that's not the case, discuss the open items with Kubo maintainers and update the release schedule accordingly. + - [ ] Create `docs-release-vX.Y.Z` branch, open a draft PR and keep updating `docs/RELEASE_ISSUE_TEMPLATE.md` on that branch as you go. + - [ ] Ensure you have a [GPG key generated](https://docs.github.com/en/authentication/managing-commit-signature-verification/generating-a-new-gpg-key) and [added to your GitHub account](https://docs.github.com/en/authentication/managing-commit-signature-verification/adding-a-gpg-key-to-your-github-account). This will enable you to created signed tags. + - [ ] Ensure you have [admin access](https://discuss.ipfs.tech/g/admins) to [IPFS Discourse](https://discuss.ipfs.tech/). Admin access is required to globally pin posts and create banners. @2color might be able to assist you. + - [ ] Access to [#bifrost](https://filecoinproject.slack.com/archives/C03MMMF606T) channel in FIL Slack might come in handy. Ask the release reviewer to invite you over. + - [ ] Access to [#shared-pl-marketing-requests](https://filecoinproject.slack.com/archives/C018EJ8LWH1) channel in FIL Slack will be required to request social shares. Ask the release reviewer to invite you over. + - [ ] After the release is deployed to our internal infrastructure, you're going to need read access to [IPFS network metrics](https://github.com/protocol/pldw/blob/624f47cf4ec14ad2cec6adf601a9f7b203ef770d/docs/sources/ipfs.md#ipfs-network-metrics) dashboards. Open an access request in https://github.com/protocol/pldw/issues/new/choose if you don't have it yet ([example](https://github.com/protocol/pldw/issues/158)). + - [ ] You're also going to need NPM installed on your system. See [here](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) for instructions. + - [ ] Prepare changelog proposal in [docs/changelogs/vX.Y.md](https://github.com/ipfs/kubo/blob/master/docs/changelogs/). + - Skip filling out the `### Changelog` section (the one where which lists all the commits and contributors) for now. We will populate it after the release branch is cut. + - [ ] Install ZSH ([instructions](https://github.com/ohmyzsh/ohmyzsh/wiki/Installing-ZSH#install-and-set-up-zsh-as-default)). It is needed by the changelog creation script. + - [ ] Ensure you have `kubo` checked out under `$(go env GOPATH)/src/github.com/ipfs/kubo`. This is required by the changelog creation script. + - If you want your clone to live in a different location, you can symlink it to the expected location by running `mkdir -p $(go env GOPATH)/src/github.com/ipfs && ln -s $(pwd) $(go env GOPATH)/src/github.com/ipfs/kubo`. + - [ ] Ensure that [README.md](https://github.com/ipfs/go-ipfs/tree/master/README.md) is up to date. +- [ ] **Stage 1 - Initial Preparations** + - [ ] Upgrade to the latest patch release of Go that CircleCI has published (currently used version: `1.19.1`) - [ ] See the list here: https://hub.docker.com/r/cimg/go/tags - [ ] [ipfs/distributions](https://github.com/ipfs/distributions): bump [this version](https://github.com/ipfs/distributions/blob/master/.tool-versions#L2) - [ ] [ipfs/kubo](https://github.com/ipfs/kubo): [example PR](https://github.com/ipfs/kubo/pull/8599) - - [ ] Fork a new branch (`release-vX.Y.Z`) from `master` and make any further release related changes to this branch. If any "non-trivial" changes (see the footnotes of [docs/releases.md](https://github.com/ipfs/go-ipfs/tree/master/docs/releases.md) for a definition) get added to the release, uncheck all the checkboxes and return to this stage. - - [ ] Follow the RC release process to cut the first RC. - - [ ] Bump the version in `version.go` in the `master` branch to `vX.(Y+1).0-dev`. - - [ ] Automated Testing (already tested in CI) - Ensure that all tests are passing, this includes: - - [ ] unit, sharness, cross-build, etc (`make test`) - - [ ] lint (`make test_go_lint`) - - [ ] [interop](https://github.com/ipfs/interop#test-with-a-non-yet-released-version-of-go-ipfs) + - [ ] [ipfs/ipfs-docs](https://github.com/ipfs/ipfs-docs): [example PR](https://github.com/ipfs/ipfs-docs/pull/1298) + - [ ] Fork a new branch (`release-vX.Y.Z`) from `master`. + - [ ] Bump the version in `version.go` in the `master` branch to `vX.(Y+1).0-dev` via a PR ([example](https://github.com/ipfs/kubo/pull/9305)). +- [ ] **Stage 2 - Release Candidate** - _if any [non-trivial](docs/releases.md#footnotes) changes need to be included in the release, return to this stage_ + - [ ] Bump the version in `version.go` in the `release-vX.Y.Z` branch to `vX.Y.Z-rcN`. + - [ ] If applicable, add new commits to the `release-vX.Y.Z` branch from `master` using `git cherry-pick -x ...` + - Note: `release-*` branches are protected. You can do all needed updates on a separated branch (e.g. `wip-release-vX.Y.Z`) and when everything is settled push to `release-vX.Y.Z` + - [ ] Push the `release-vX.Y.Z` branch to GitHub (`git push origin release-vX.Y.Z`) and create a draft PR targetting `release` branch if it doesn't exist yet ([example](https://github.com/ipfs/kubo/pull/9306)). + - [ ] Wait for CI to run and complete PR checks. All checks should pass. + - [ ] Create a signed tag for the release candidate. + - [ ] This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing. Remember to verify the commands you intend to run for items marked with ⚠️ with the release reviewer. + - [ ] ⚠️ Tag HEAD `release-vX.Y.Z` commit with `vX.Y.Z-rcN` (`git tag -s vX.Y.Z-rcN -m 'Pre-release X.Y.Z-rcn'`) + - [ ] Run `git show vX.Y.Z` to ensure the tag is correct. + - [ ] ⚠️ Push the `vX.Y.Z` tag to GitHub (`git push origin vX.Y.Z`; DO NOT USE `git push --tags` because it pushes all your local tags). + - [ ] Add artifacts to https://dist.ipfs.tech by making a PR against [ipfs/distributions](https://github.com/ipfs/distributions) + - [ ] Clone the `ipfs/distributions` repo locally. + - [ ] Create a new branch (`kubo-release-vX.Y.Z-rcn`) from `master`. + - [ ] Run `./dist.sh add-version kubo vX.Y.Z-rcN` to add the new version to the `versions` file ([instructions](https://github.com/ipfs/distributions#usage)). + - `dist.sh` will print _WARNING: not marking pre-release kubo vX.Y.Z-rc1n as the current version._. + - [ ] Push the `kubo-release-vX.Y.Z-rcn` branch to GitHub and create a PR from that branch ([example](https://github.com/ipfs/distributions/pull/760)). + - [ ] Ask for a review from the release reviewer. + - [ ] Enable auto-merge for the PR. + - PR build will build the artifacts and generate a diff in around 30 minutes + - PR will be merged automatically once the diff is approved + - `master` build will publish the artifacts to https://dist.ipfs.io in around 30 minutes + - [ ] Ensure that the artifacts are available at https://dist.ipfs.io + - [ ] Publish the RC to [the NPM package](https://www.npmjs.com/package/go-ipfs?activeTab=versions) by running https://github.com/ipfs/npm-go-ipfs/actions/workflows/main.yml (it happens automatically but it is safe to speed up the process and kick of a run manually) + - [ ] Cut a pre-release on [GitHub](https://github.com/ipfs/kubo/releases) ([instructions](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release), [example](https://github.com/ipfs/kubo/releases/tag/v0.16.0-rc1)) + - Use `vX.Y.Z-rcN` as the tag. + - Link to the release issue in the description. + - Link to the relevant [changelog](https://github.com/ipfs/kubo/blob/master/docs/changelogs/) in the description. + - Check `This is a pre-release`. + - [ ] Synchronize release artifacts by running [sync-release-assets](https://github.com/ipfs/kubo/actions/workflows/sync-release-assets.yml) workflow. + - [ ] Announce the RC + - [ ] Create a new post on [IPFS Discourse](https://discuss.ipfs.tech). ([example](https://discuss.ipfs.tech/t/kubo-v0-16-0-rc1-release-candidate-is-out/15248)) + - Use `Kubo vX.Y.Z-rcn Release Candidate is out!` as the title. + - Use `kubo` and `go-ipfs` as topics. + - Repeat the title as a heading (`##`) in the description. + - Link to the GitHub Release, binaries on IPNS, docker pull command and release notes in the description. + - [ ] Pin the topic globally so that it stays at the top of the category. + - [ ] If there is no more important banner currently set on Discourse (e.g. IPFS Camp announcement), make the topic into a banner. + - [ ] Check if Discourse post was automatically copied to: + - [ ] IPFS Discord #ipfs-chatter + - [ ] FIL Slack #ipfs-chatter + - [ ] Matrix https://matrix.to/#/#ipfs-chatter:ipfs.io + - [ ] Mention [early testers](https://github.com/ipfs/go-ipfs/tree/master/docs/EARLY_TESTERS.md) in the comment under the release issue ([example](https://github.com/ipfs/kubo/issues/9237#issuecomment-1258072509)). +- [ ] **Stage 3 - Internal Testing** + - [ ] Library Testing. + - [ ] [interop](https://github.com/ipfs/interop) + - [ ] Clone the `ipfs/interop` repo locally. + - [ ] Create a new branch (`kubo-release-vX.Y.Z-rcn`) from `master`. + - [ ] Update `go-ipfs` version to `vX.Y.Z-rcN` in [package.json](https://github.com/ipfs/interop/blob/master/package.json). + - [ ] Run `npm install` locally + - [ ] Push the `kubo-release-vX.Y.Z-rcn` branch to GitHub and create a draft PR from that branch ([example](https://github.com/ipfs/interop/pull/511)). - [ ] [go-ipfs-api](https://github.com/ipfs/go-ipfs-api) + - [ ] Create a branch with kubo version pinned in the [test setup action](https://github.com/ipfs/go-ipfs-api/blob/master/.github/actions/go-test-setup/action.yml) ([example](https://github.com/ipfs/go-ipfs-api/commit/d156b808cc3aebafba65a38e5dd6993543a50e82)). + - [ ] Ensure that CI is green. + - [ ] Delete the branch. - [ ] [go-ipfs-http-client](https://github.com/ipfs/go-ipfs-http-client) + - [ ] Create a branch with kubo version pinned in the [test setup action](https://github.com/ipfs/go-ipfs-http-client/blob/master/.github/actions/go-test-setup/action.yml) ([example](https://github.com/ipfs/go-ipfs-http-client/commit/8a057960d26f1c60fffef09be3b05ec3f2e71bba)). + - [ ] Ensure that CI is green. + - [ ] Delete the branch. - [ ] [WebUI](https://github.com/ipfs-shipyard/ipfs-webui) -- [ ] **Stage 1 - Internal Testing** - - [ ] CHANGELOG.md has been updated - - use [`./bin/mkreleaselog`](https://github.com/ipfs/go-ipfs/tree/master/bin/mkreleaselog) to generate a nice starter list - - you need to install `zsh`. - - [ ] Infrastructure Testing. - - [ ] Open an issue against https://github.com/protocol/bifrost-infra and spell out all that we want (e.g.,mgateways, bootstrapper, and cluster). [example](https://github.com/protocol/bifrost-infra/issues/2046) - - [ ] Deploy new version to a subset of Bootstrappers - - [ ] Deploy new version to a subset of Gateways - - [ ] Deploy new version to a subset of Preload nodes - - [ ] Collect [metrics](https://protocollabs.grafana.net/d/8zlhkKTZk/gateway-slis-precomputed?orgId=1) every day. Work with the Infrastructure team to learn of any hiccup - - [ ] IPFS Application Testing - Run the tests of the following applications: + - [ ] Run [CI workflow](https://github.com/ipfs/ipfs-webui/actions/workflows/ci.yml) with `vX.Y.Z-rcN` for the `kubo-version` input. + - [ ] Ensure that CI is green. + - [ ] Infrastructure Testing. + - [ ] Update the issue against [bifrost-infra](https://github.com/protocol/bifrost-infra) ([example](https://github.com/protocol/bifrost-infra/issues/2109)). + - [ ] Mention @protocol/bifrost-team in the issue to let them know the release is ready + - [ ] [Optional] Reply under a message about the issue in the #bifrost channel on FIL Slack once the RC is out. Send the message to the channel. + - [ ] Check [metrics](https://protocollabs.grafana.net/d/8zlhkKTZk/gateway-slis-precomputed?orgId=1) every day. + - Compare the metrics trends week over week. + - If there is an unexpected variation in the trend, message the #bifrost channel on FIL Slack and ask for help investigation the cause. + - [ ] IPFS Application Testing. - [ ] [IPFS Desktop](https://github.com/ipfs-shipyard/ipfs-desktop) - - [ ] Ensure the RC is published to [the NPM package](https://www.npmjs.com/package/go-ipfs?activeTab=versions) ([happens automatically, just wait for CI](https://github.com/ipfs/npm-go-ipfs/actions)) - - [ ] Upgrade to the RC in [ipfs-desktop](https://github.com/ipfs-shipyard/ipfs-desktop) and push to a branch ([example](https://github.com/ipfs/ipfs-desktop/pull/1826/commits/b0a23db31ce942b46d95965ee6fe770fb24d6bde)), and open a draft PR to track through the final release ([example](https://github.com/ipfs/ipfs-desktop/pull/1826)) - - [ ] Ensure CI tests pass, repeat for new RCs + - [ ] Upgrade to the RC in [ipfs-desktop](https://github.com/ipfs-shipyard/ipfs-desktop) + - [ ] Run `npm install` to update `package-lock.json`. + - [ ] Push to a branch ([example](https://github.com/ipfs/ipfs-desktop/pull/1826/commits/b0a23db31ce942b46d95965ee6fe770fb24d6bde)) + - [ ] Open a draft PR to track through the final release ([example](https://github.com/ipfs/ipfs-desktop/pull/1826)) + - [ ] Ensure CI tests pass - [ ] [IPFS Companion](https://github.com/ipfs-shipyard/ipfs-companion) - - Start kubo daemon of the version to release. - - Start a fresh chromium or chrome instance using `chromium --user-data-dir=$(mktemp -d)` - - Start a fresh firefox instance using `firefox --profile $(mktemp -d)` - - Install IPFS Companion from [vendor-specific store](https://github.com/ipfs/ipfs-companion/#readme). - - Check that the comunication between Kubo daemon and IPFS companion is working properly checking if the number of connected peers changes. -- [ ] **Stage 2 - Community Prod Testing** - - [ ] Documentation - - [ ] Ensure that [CHANGELOG.md](https://github.com/ipfs/go-ipfs/tree/master/CHANGELOG.md) is up to date - - [ ] Add a link from release notes to Discuss post (like we did here: https://github.com/ipfs/kubo/releases/tag/v0.15.0 ) - - [ ] Keep the release notes as trim as possible (removing some of the top headers, like we did here: https://github.com/ipfs/kubo/releases/tag/v0.15.0 ) - - [ ] Ensure that [README.md](https://github.com/ipfs/go-ipfs/tree/master/README.md) is up to date - - [ ] Update docs by merging the auto-created PR in https://github.com/ipfs/ipfs-docs/pulls (they are auto-created every 12 hours) (only for final releases, not RCs) - - [ ] Invite the wider community through (link to the release issue): - - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements) - - [ ] Matrix -- [ ] **Stage 3 - Release** - - [ ] Final preparation - - [ ] Verify that version string in [`version.go`](https://github.com/ipfs/go-ipfs/tree/master/version.go) has been updated. - - [ ] Open a PR merging `release-vX.Y.Z` into the `release` branch. - - This should be reviewed by the person who most recently released a version of `go-ipfs`. - - Use a merge commit (no rebase, no squash) - - [ ] Prepare the command to use for tagging the merge commit (on the `release` branch) with `vX.Y.Z`. - - Use `git tag -s` to ensure the tag is signed - - [ ] Have the tagging command reviewed by the person who most recently released a version of `go-ipfs` - - This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing - - [ ] Push the tag - - Use `git push origin ` - - DO NOT USE `git push --tags`, as it will push ALL of your local tags - - This should initiate a Docker build in GitHub Actions that publishes a `vX.Y.Z` tagged Docker image to DockerHub - - [ ] Release published - - [ ] to [dist.ipfs.tech](https://dist.ipfs.tech) - - [ ] to [npm-go-ipfs](https://www.npmjs.com/package/go-ipfs) (done by CI at [ipfs/npm-go-ipfs](https://github.com/ipfs/npm-go-ipfs), but ok to dispatch [this job](https://github.com/ipfs/npm-go-ipfs/actions/workflows/main.yml) manually) - - [ ] to [chocolatey](https://chocolatey.org/packages/go-ipfs) (done by CI at [ipfs/choco-go-ipfs](https://github.com/ipfs/choco-go-ipfs/), but ok to dispatch [this job](https://github.com/ipfs/choco-go-ipfs/actions/workflows/main.yml) manually) - - [ ] Manually run [the release workflow](https://github.com/ipfs/choco-go-ipfs/actions/workflows/main.yml) - - [ ] Wait for Chocolatey to approve the release (usually takes a few hours) - - [ ] to [snap](https://snapcraft.io/ipfs) (done CI at [snap/snapcraft.yaml](https://github.com/ipfs/kubo/blob/master/snap/snapcraft.yaml)) - - [ ] to [github](https://github.com/ipfs/go-ipfs/releases) - - [ ] After publishing the GitHub release, run the workflow to attach the release assets: https://github.com/ipfs/go-ipfs/actions/workflows/sync-release-assets.yml - - [ ] to [arch](https://www.archlinux.org/packages/community/x86_64/go-ipfs/) (flag it out of date) - - [ ] Cut a new ipfs-desktop release - - [ ] Get a blog post created - - [Submit a request using this form](https://airtable.com/shrNH8YWole1xc70I). - - Notify marketing in #shared-pl-marketing-requests about the blog entry request (since the form gets spam). - - Don't mark this as done until the blog entry is live. - - [ ] Broadcasting (link to blog post) - - [ ] Twitter (request in Filecoin Slack channel #shared-pl-marketing-requests) - - [ ] [Reddit](https://reddit.com/r/ipfs) - - [ ] [discuss.ipfs.io](https://discuss.ipfs.io/c/announcements) - - A bot auto-posts this to Discord and Matrix -- [ ] **Post-Release** + - [ ] Start kubo daemon of the version to release. + - [ ] Start a fresh chromium or chrome instance using `chromium --user-data-dir=$(mktemp -d)` (macos `/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=$(mktemp -d)`) + - [ ] Start a fresh firefox instance using `firefox --profile $(mktemp -d)` (macos `/Applications/Firefox.app/Contents/MacOS/firefox --profile $(mktemp -d)`) + - [ ] Install IPFS Companion from [vendor-specific store](https://github.com/ipfs/ipfs-companion/#readme). + - [ ] Check that the comunication between Kubo daemon and IPFS companion is working properly checking if the number of connected peers changes. +- [ ] **Stage 5 - Release** - _ONLY FOR FINAL RELEASE_ + - [ ] Prepare the `release` branch. + - [ ] Bump the version in `version.go` in the `release-vX.Y.Z` branch to `vX.Y.Z`. + - [ ] Update the [docs/changelogs/vX.Y.md](docs/changelogs) with the new commits and contributors. + - [ ] Run `./bin/mkreleaselog` twice to generate the changelog and copy the output. + - The first run of the script might be poluted with `git clone` output. + - [ ] Paste the output into the `### Changelog` section of the changelog file inside the `
` block. + - [ ] Commit the changelog changes. + - [ ] Push the `release-vX.Y.Z` branch to GitHub (`git push origin release-vX.Y.Z`) + - [ ] Mark the PR created from `release-vX.Y.Z` as ready for review. + - [ ] Ensure the PR is targetting `release` branch. + - [ ] Ensure that CI is green. + - [ ] Have release reviewer review the PR. + - [ ] Merge the PR into `release` branch using the `Create a merge commit` (do **NOT** use `Squash and merge` nor `Rebase and merge` because we need to be able to sign the merge commit). + - Do not delete the `release-vX.Y.Z` branch. + - [ ] Checkout the `release` branch locally. + - Remember to pull the latest changes. + - [ ] Create a signed tag for the release. + - [ ] This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing. Remember to verify the commands you intend to run for items marked with ⚠️ with the release reviewer. + - [ ] ⚠️ Tag HEAD `release` commit with `vX.Y.Z` (`git tag -s vX.Y.Z -m 'Release X.Y.Z'`) + - [ ] Run `git show vX.Y.Z` to ensure the tag is correct. + - [ ] ⚠️ Push the `vX.Y.Z` tag to GitHub (`git push origin vX.Y.Z`; DO NOT USE `git push --tags` because it pushes all your local tags). + - [ ] Publish the release. + - [ ] Wait for [Publish docker image](https://github.com/ipfs/kubo/actions/workflows/docker-image.yml) workflow run initiated by the tag push to finish. + - [ ] Add artifacts to https://dist.ipfs.tech by making a PR against [ipfs/distributions](https://github.com/ipfs/distributions) + - [ ] Clone the `ipfs/distributions` repo locally. + - [ ] Create a new branch (`kubo-release-vX.Y.Z`) from `master`. + - [ ] Run `./dist.sh add-version kubo vX.Y.Z` to add the new version to the `versions` file ([instructions](https://github.com/ipfs/distributions#usage)). + - [ ] Push the `kubo-release-vX.Y.Z` branch to GitHub and create a PR from that branch ([example](https://github.com/ipfs/distributions/pull/768)). + - [ ] Ask for a review from the release reviewer. + - [ ] Enable auto-merge for the PR. + - PR build will build the artifacts and generate a diff in around 30 minutes + - PR will be merged automatically once the diff is approved + - `master` build will publish the artifacts to https://dist.ipfs.io in around 30 minutes + - [ ] Ensure that the artifacts are available at https://dist.ipfs.io + - [ ] Publish the release to [the NPM package](https://www.npmjs.com/package/go-ipfs?activeTab=versions) by running https://github.com/ipfs/npm-go-ipfs/actions/workflows/main.yml (it happens automatically but it is safe to speed up the process and kick of a run manually) + - [ ] Cut the release on [GitHub](https://github.com/ipfs/kubo/releases) ([instructions](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release), [example](https://github.com/ipfs/kubo/releases/tag/v0.16.0)) + - Use `vX.Y.Z` as the tag. + - Link to the release issue in the description. + - Copy the relevant [changelog](https://github.com/ipfs/kubo/blob/release/docs/changelogs/) into the release description. + - Keep the release notes as trim as possible (e.g. remove top headers where possible, [example](https://github.com/ipfs/kubo/releases/tag/v0.15.0)) + - [ ] Synchronize release artifacts by running [sync-release-assets](https://github.com/ipfs/kubo/actions/workflows/sync-release-assets.yml) workflow. + - [ ] Announce the release + - [ ] Add a link to the release to this release issue as a comment. + - [ ] Create a new post on [IPFS Discourse](https://discuss.ipfs.tech). ([example](https://discuss.ipfs.tech/t/kubo-v0-16-0-release-is-out/15286)) + - Use `Kubo vX.Y.Z Release is out!` as the title. + - Use `kubo` and `go-ipfs` as topics. + - Repeat the title as a heading (`##`) in the description. + - Link to the GitHub Release, binaries on IPNS, docker pull command and release notes in the description. + - [ ] Pin the topic globally so that it stays at the top of the category. + - [ ] If there is no more important banner currently set on Discourse (e.g. IPFS Camp announcement), make the topic into a banner. + - [ ] Check if Discourse post was automatically copied to: + - [ ] IPFS Discord #ipfs-chatter + - [ ] FIL Slack #ipfs-chatter + - [ ] Matrix + - [ ] Add a link from release notes to Discuss post (like we did here: https://github.com/ipfs/kubo/releases/tag/v0.15.0) + - [ ] Update the draft PR created for [interop](https://github.com/ipfs/interop) to use the new release and mark it as ready for review. + - [ ] Update the draft PR created for [IPFS Desktop](https://github.com/ipfs-shipyard/ipfs-desktop) to use the new release and mark it as ready for review. + - [ ] Update docs + - [ ] Run https://github.com/ipfs/ipfs-docs/actions/workflows/update-on-new-ipfs-tag.yml to generate a PR to the docs repo + - [ ] Merge the auto-created PR in https://github.com/ipfs/ipfs-docs/pulls ([example](https://github.com/ipfs/ipfs-docs/pull/1263)) + - [ ] Get the blog post created and shared + - [ ] Submit a request for blog post creation using [the form](https://airtable.com/shrNH8YWole1xc70I). + - Notify marketing in #shared-pl-marketing-requests about the blog entry request (since the form tends to go to spam; [example]([example](https://filecoinproject.slack.com/archives/C018EJ8LWH1/p1664885305374909))). + - Don't mark this as done until the blog entry is live. + - [ ] Share the blog post + - [ ] Twitter (request in Filecoin Slack channel #shared-pl-marketing-requests; [example](https://filecoinproject.slack.com/archives/C018EJ8LWH1/p1664903524843269?thread_ts=1664885305.374909&cid=C018EJ8LWH1)) + - [ ] [Reddit](https://reddit.com/r/ipfs) +- [ ] **Stage 6 - Post-Release** - [ ] Merge the `release` branch back into `master`, ignoring the changes to `version.go` (keep the `-dev` version from master). - [ ] Create an issue using this release issue template for the _next_ release. - - [ ] Make sure any last-minute changelog updates from the blog post make it back into the CHANGELOG. - - [ ] Mark PR draft created for IPFS Desktop as ready for review. - -## ⁉️ Do you have questions? - -The best place to ask your questions about IPFS, how it works and what you can do with it is at [discuss.ipfs.io](http://discuss.ipfs.io). We are also available at the `#ipfs` channel on Freenode, which is also [accessible through our Matrix bridge](https://riot.im/app/#/room/#freenode_#ipfs:matrix.org). - -## Release improvements for next time - -< Add any release improvements that were observed this cycle here so they can get incorporated into future releases. > - -## Items for a separate comment - -< Do these as a separate comment to avoid the main issue from getting too large and checkbox updates taking too long. > - -### Changelog - -< changelog generated by bin/mkreleaselog > (add it to a separated comment if it is too big) - -### ❤️ Contributors + - [ ] Close this release issue. -< list generated by bin/mkreleaselog > +## How to contribute? Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started: diff --git a/docs/releases.md b/docs/releases.md index 25111d4b149..d42feea7bc8 100644 --- a/docs/releases.md +++ b/docs/releases.md @@ -16,6 +16,7 @@ - [Security Fix Policy](#security-fix-policy) - [Performing a Release](#performing-a-release) - [Release Version Numbers (aka semver)](#release-version-numbers-aka-semver) + - [_Footnotes_](#footnotes) ## Release Philosophy @@ -112,5 +113,7 @@ We do not yet retroactively apply fixes to older releases (no Long Term Support ---------------------------- +## _Footnotes_ + - **[1]** - _early testers_ is an IPFS programme in which members of the community can self-volunteer to help test `kubo` Release Candidates. You find more info about it at [EARLY_TESTERS.md](./EARLY_TESTERS.md) - **[2]** - A non-trivial change is any change that could potentially introduce an issue not trivially caught by automated testing. This is up to the discretion of the Lead Maintainer but the assumption is that every change is non-trivial unless proven otherwise.