Release Issue Template
We're happy to announce go-ipfs 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>
<Date this release will ship on if everything goes to plan (week beginning...)>
< 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). - tag commit with
vX.Y.Z-rcN
- upload to dist.ipfs.io
- Build: https://github.com/ipfs/distributions#usage.
- Pin the resulting release.
- Make a PR against ipfs/distributions with the updated versions, including the new hash in the PR comment.
- Ask the infra team to update the DNSLink record for dist.ipfs.io to point to the new distribution.
- cut a pre-release on github and upload the result of the ipfs/distributions build in the previous step.
- Announce the RC:
- On Matrix (both #ipfs and #ipfs-dev)
- 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/go-ipfs: 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. - Merge
release-vX.Y.Z
into therelease
branch. - Tag this merge commit (on the
release
branch) withvX.Y.Z
. - Release published
- to dist.ipfs.io
- to npm-go-ipfs
- to chocolatey
- to snap
- to github
- use the artifacts built in CI for dist.ipfs.io:
wget "https://ipfs.io/api/v0/get?arg=/ipns/dist.ipfs.io/go-ipfs/$(curl -s https://dist.ipfs.io/go-ipfs/versions | tail -n 1)"
- use the artifacts built in CI for dist.ipfs.io:
- to arch (flag it out of date)
- Cut a new ipfs-desktop release
- Verify that version string in
- Submit this form to publish a blog post, linking to the GitHub release notes
- Broadcasting (link to blog post)
- Twitter (request in Slack channel #pl-marketing-requests)
- Matrix
- discuss.ipfs.io
- Announce it on the IPFS Users Mailing List
- 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 go-ipfs 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!