Release v0.14

[guseggert]

go-ipfs 0.14.0 Release

We're happy to announce go-ipfs 0.14.0, 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.

🗺 What's left for release

🚢 Estimated shipping date

RC: week of 2022-07-04 (2022-07-07)
Final release: 2022-07-20

🔦 Highlights

< top highlights for this release notes >

✅ Release Checklist

Before doing the following:

• Rename go-ipfs repo

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 ...
• tag commit with vX.Y.Z-rcN
• upload to dist.ipfs.io
  1. Build: https://github.com/ipfs/distributions#usage.
  2. Pin the resulting release.
  3. Make a PR against ipfs/distributions with the updated versions, including the new hash in the PR comment.
  4. 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) from master 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 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
    • go-ipfs-api
    • go-ipfs-http-client
    • WebUI
• Stage 1 - Internal Testing
  • CHANGELOG.md has been updated
    • use ./bin/mkreleaselog to generate a nice starter list
  • Infrastructure Testing:
    • Deploy new version to a subset of Bootstrappers
    • Deploy new version to a subset of Gateways: https://github.com/protocol/bifrost-infra/issues/2002
    • 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
• 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 (message forwarded from discuss)
• Stage 3 - Release
  • Final preparation
    • Verify that version string in 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
        (This has been done with one single person since I made two versions back to back, is that ok in the future ?)
    • 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
    • Release published
      • to dist.ipfs.io
      • to npm-go-ipfs
      • to chocolatey
        • Manually run the release workflow
        • Wait for Chocolatey to approve the release (usually takes a few hours)
      • to snap
      • 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)
      • Merge refactor: rename go-ipfs to kubo ipfs-docs#1185
    • Cut a new ipfs-desktop release
  • Submit this form to publish a blog post, linking to the GitHub release notes
  • Broadcasting
    • Twitter (request in Slack channel #pl-marketing-requests)
    • Reddit
    • discuss.ipfs.io
      • A bot auto-posts this to Discord and Matrix
• 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. We are also available at the #ipfs channel on Freenode, which is also accessible through our Matrix bridge.

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 >

❤️ Contributors

< 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!

[aschmahmann]

Placeholder

[lidel]

When we have v0.14.0-rc1 git tag, the build in already existing ipfs/distributions#717 needs to be re-run.

[BigLep]

Let's collect release template improvements here: #9100

[BigLep]

@Jorropo : concerning the Kubo 0.14 release, I’ve been thinking on this more. I think we should prioritize seeing if we can get this change out this week (week of 2022-07-18) because it is holding up the big docs change (ipfs/ipfs-docs#1185 ), and I expect various folks are going to want to make docs changes as a result of the IPFS Thing event. Understood if you’re needing to take some rest time. When you’re not resting, I’d like to prioritize this by:

1. Engaging with #bifrost to get this deployed ASAP so we can start looking at the metrics. (I'll start and CC you on the thread.)
2. Lets not work on testing reframe on the gateways currently. Given it isn’t turned on by default and we have a sharness test for it, I don’t think it’s important to flex it in production. I think it’s more important to get the release out. We’ll test it more on the gateways before we turn it on for the gateways.

Sound good and make sense?