Release Issue Template. If doing a patch release, see here
- Fill in the Meta section
- Assign the issue to the release owner and reviewer.
- Name the issue "Release vX.Y.Z"
- Set the proper values for X.Y.Z
- Pin the issue
- Release owner: @who
- Release reviewer: @who
- Expected RC date: week of 2022-MM-DD
- 🚢 Expected final release date: 2022-MM-DD
- Accompanying PR for improving the release process: (example: ipfs#9100)
See the Kubo release process for more info.
We're happy to announce Kubo X.Y.Z, bla bla...
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 for details.
<List of items with PRs and/or Issues to be considered for this release>
< top highlights for this release notes >
For each RC published in each stage:
- version string in
version.go
has been updated (in therelease-vX.Y.Z
branch). - new commits should be added to the
release-vX.Y.Z
branch frommaster
usinggit cherry-pick -x ...
- tag commit with
vX.Y.Z-rcN
- add artifacts to https://dist.ipfs.tech
- Make a PR against ipfs/distributions with local changes produced by
add-version
(see usage) - Wait for PR to build artifacts and generate diff
- Inspect results, merge if CI is green and the diff looks ok
- Wait for
master
branch to build and update DNSLink at https://dist.ipfs.tech
- Make a PR against ipfs/distributions with local changes produced by
- cut a pre-release on github 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:
-
- This will automatically post to IPFS Discord #ipfs-chatter
- Examples from the past: 0.14.0
- Pin the topic
- To the early testers listed in docs/EARLY_TESTERS.md. Do this by copy/pasting their GitHub usernames and checkboxes as a comment so they get a GitHub notification. (example)
-
Checklist:
- Stage 0 - Automated Testing
- Upgrade to the latest patch release of Go that CircleCI has published
- See the list here: https://hub.docker.com/r/cimg/go/tags
- ipfs/distributions: bump this version
- ipfs/kubo: example PR
- Fork a new branch (
release-vX.Y.Z
) frommaster
and make any further release related changes to this branch. If any "non-trivial" changes (see the footnotes of 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 themaster
branch tovX.(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
- go-ipfs-api
- go-ipfs-http-client
- WebUI
- unit, sharness, cross-build, etc (
- Upgrade to the latest patch release of Go that CircleCI has published
- Stage 1 - Internal Testing
- CHANGELOG.md has been updated
- use
./bin/mkreleaselog
to generate a nice starter list
- use
- Infrastructure Testing:
- 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 every day. Work with the Infrastructure team to learn of any hiccup
- IPFS Application Testing - Run the tests of the following applications:
- IPFS Desktop
- Ensure the RC is published to the NPM package (happens automatically, just wait for CI)
- Upgrade to the RC in ipfs-desktop and push to a branch (example), and open a draft PR to track through the final release (example)
- Ensure CI tests pass, repeat for new RCs
- IPFS Companion - @lidel
- IPFS Desktop
- CHANGELOG.md has been updated
- Stage 2 - Community Prod Testing
- Documentation
- Ensure that CHANGELOG.md is up to date
- Ensure that 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)
- Invite the wider community through (link to the release issue):
- discuss.ipfs.io
- Matrix
- Documentation
- Stage 3 - Release
- Final preparation
- Verify that version string in
version.go
has been updated. - Open a PR merging
release-vX.Y.Z
into therelease
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)
- This should be reviewed by the person who most recently released a version of
- Prepare the command to use for tagging the merge commit (on the
release
branch) withvX.Y.Z
.- Use
git tag -s
to ensure the tag is signed
- Use
- 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 <tag>
- 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
- Use
- Release published
- to dist.ipfs.tech
- to npm-go-ipfs (done by CI at ipfs/npm-go-ipfs, but ok to dispatch this job manually)
- to chocolatey (done by CI at ipfs/choco-go-ipfs, but ok to dispatch this job manually)
- Manually run the release workflow
- Wait for Chocolatey to approve the release (usually takes a few hours)
- to snap (done CI at snap/snapcraft.yaml)
- to github
- 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 (flag it out of date)
- Cut a new ipfs-desktop release
- Verify that version string in
- Get a blog post created
- Submit a request using this form.
- 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)
- discuss.ipfs.io
- A bot auto-posts this to Discord and Matrix
- Final preparation
- Post-Release
- Merge the
release
branch back intomaster
, ignoring the changes toversion.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.
- Merge the
The best place to ask your questions about IPFS, how it works and what you can do with it is at discuss.ipfs.io. We are also available at the #ipfs
channel on Freenode, which is also accessible through our Matrix bridge.
< Add any release improvements that were observed this cycle here so they can get incorporated into future releases. >
< Do these as a separate comment to avoid the main issue from getting too large and checkbox updates taking too long. >
< changelog generated by bin/mkreleaselog >
< list generated by bin/mkreleaselog >
Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:
- Check the issues with the
help wanted
label in the ipfs/kubo repo - Join an IPFS All Hands, introduce yourself and let us know where you would like to contribute - https://github.com/ipfs/team-mgmt/#weekly-ipfs-all-hands
- Hack with IPFS and show us what you made! The All Hands call is also the perfect venue for demos, join in and show us what you built
- Join the discussion at discuss.ipfs.io and help users finding their answers.
- Join the 🚀 IPFS Core Implementations Weekly Sync 🛰 and be part of the action!