Release 0.32

[gammazero]

Meta

• Release owner: @lidel
• Release reviewer: @gammazero
• Expected RC1 date: Wed 30th
• Expected RC2 date: Wed 6th
• 🚢 Expected final release date: Wed 13th
• Release PR: Release v0.32.0 #10563
• Accompanying PR for improving the release process: docs: update RELEASE_CHECKLIST.md #10564
• Internal Staging tests by Shipyard: https://www.notion.so/Kubo-0-31-0-vs-0-32-0-12f1def3428780c0acd4cbdb4b14598a
• Changelog: https://github.com/ipfs/kubo/blob/master/docs/changelogs/v0.32.md

Items In Scope

Required

• chore: update dependencies #10548
• feat(AutoTLS): opt-in WSS certs from p2p-forge at libp2p.direct #10521
  • as opt-in for now

Fixes for things found in RC:

• fix(autotls): store certificates at the location from the repo path #10566
• https://github.com/ipfs/kubo/security/dependabot/99
• chore: update deps #10569
• AutoTLS:fix(client): wait for public reachability before registering ipshipyard/p2p-forge#4
• chore: [email protected] #10571
• chore: boxo v0.24.3 and p2p-forge v0.0.2 #10572
• feat: ipfs-webui v4.4.0 #10574
• fix: go-libp2p-kad-dht v0.28.0 #10578

Nice To Have (Optional)

• fix: do not include full path to binary in .sha512 files distributions#1108
• AutoTLS acme_client "got renewal info" (logger does not respect go-log config) ipshipyard/p2p-forge#8 (comment)
• AutoTLS on the same port as raw TCP if we have go-ipfs release with Use the same port for TCP and WebSocket libp2p/go-libp2p#2684
• AutoTLS: AutoTLS: attempts to get cert when not publicly diallable #10570
• AutoTLS: add flag for adding catch-all listener without touching swarm listeners in config
• chore: stop using go-homedir #10568
• Denylist support fixes and improvements
  • Support legacy double-hash entries for IPNS CIDs and DNSLink ipfs-shipyard/nopfs#40
  • ipfs blockservice is incompatible with sessions ipfs-shipyard/nopfs#34 (NOfs content filtering is not applied to bitswap)
  • Support consuming https://badbits.dwebops.pub/badbits.deny rainbow#126 (same applies to Kubo)
    • denylist: ?format=car does not skip directly blocked CIDs #10361
    • HTTPSubscriber: detect when list is not append-only ipfs-shipyard/nopfs#39
    • HTTPSubscriber: check with If-None-Match or If-Modified-Since ipfs-shipyard/nopfs#38
• Update pubsub and add default validator #9684 + update to v0.12.0 with GossipSub v1.2
• Add basic UnixFS sanity check to 'ipfs files cp' #10331
• feat(filestore): add mmap reader option boxo#665 disabled by default, with opt-in variable similar to this or this
• Prevent multiple instances of "ipfs bitswap reprovide" running at the same time #10513
• gateway/blocks-backend: GetBlock should not perform IPLD decoding boxo#673

Closes #9323

[lidel]

✅ Release Checklist (v0.32.0-rc1)

• merge docs: add note about separate port use #10562
  • resolve CI issues (pinged IPDX)
• Prepare the release branch and update version numbers accordingly
  using ./kuboreleaser --skip-check-before release --version vX.Y.Z(-rcN) prepare-branch or ...

  • create a new branch release-vX.Y.Z
    • use master as base if Z == 0
    • use release as base if Z > 0
  • update the CurrentVersionNumber in version.go in the master branch to vX.Y+1.0-dev
    • example
  • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-RCN)
    • example
  • create a draft PR from release-vX.Y to release
    • example
  • Cherry-pick commits from master to the release-vX.Y.Z using git cherry-pick -x <commit>
  • Add full changelog and contributors to the changelog
    • Replace the Changelog and Contributors sections of the changelog with the stdout of ./bin/mkreleaselog. Note that the command expects your $GOPATH/src/github.com/ipfs/kubo to include latest commits from release-vX.Y
      • do NOT copy the stderr
  • verify all CI checks on the PR from release-vX.Y to release are passing
  • Merge the PR from release-vX.Y to release 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 branch
• Create the release tag
  using ./kuboreleaser release --version vX.Y.Z(-rcN) tag or ...

  • This is a dangerous operation! Go and Docker publishing are difficult to reverse! Have the release reviewer verify all the commands marked with ⚠️!
  • ⚠️ tag the HEAD commit using git tag -s vX.Y.Z(-RCN) -m 'Prerelease X.Y.Z(-RCN)'
  • ⚠️ tag the HEAD commit of the release branch using git tag -s vX.Y.Z -m 'Release X.Y.Z'
  • ⚠️ verify the tag is signed and tied to the correct commit using git show vX.Y.Z(-RCN)
  • ⚠️ push the tag to GitHub using git push origin vX.Y.Z(-RCN)
    • do NOT use git push --tags because it pushes all your local tags
• Verify ipfs/distributions's .tool-versions's golang entry is set to the latest go release on the major go branch Kubo is being tested on (see go-version:).
• Publish to Dockerhub, NPM, and dist.ipfs.tech and GitHub using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-all or follow each step below:
  • Publish the release to DockerHub
    using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub or ...

    • Wait for Publish docker image workflow run initiated by the tag push to finish
    • verify the image is available on Docker Hub
  • Publish the release to dist.ipfs.tech
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

    • check out ipfs/distributions
    • create new branch: run git checkout -b release-kubo-X.Y.Z(-rcN)
    • run ./dist.sh add-version kubo vX.Y.Z(-RCN) to add the new version to the versions file
      • usage
    • create and merge the PR which updates dists/kubo/versions and dists/go-ipfs/versions ( and dists/kubo/current and dists/go-ipfs/current)
      • example
    • wait for the CI workflow run initiated by the merge to master to finish
    • verify the release is available on dist.ipfs.tech
  • Publish the release to NPM
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm (⚠️ you might need to run the command a couple of times because GHA might not be able to see the new distribution straight away due to caching) or ...

    • run the Release to npm workflow
    • check Release to npm workflow run logs to verify it discovered the new release
    • verify the release is available on NPM
  • Publish the release to GitHub
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-github or ...

    • create a new release on GitHub
      • RC example
      • FINAL example
      • use the vX.Y.Z(-RCN) tag
      • link to the release issue
      • link to the changelog in the description
      • check the This is a pre-release checkbox
      • copy the changelog (without the header) in the description
      • do NOT check the This is a pre-release checkbox
    • run the sync-release-assets workflow
    • wait for the sync-release-assets workflow run to finish
    • verify the release assets are present in the GitHub release
• Update Kubo staging environment, see the Running Kubo tests on staging for details.
  • Test last release against the current RC
  • Test last release against the current one
• Promote the release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

  • create an IPFS Discourse topic
    • prerelease example
    • release example
    • use Kubo vX.Y.Z(-RCN) 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 IPFS Discourse topic globally
    • you can make the topic a banner if there is no banner already
  • verify the IPFS Discourse topic was copied to:
    • #ipfs-chatter in IPFS Discord
    • #ipfs-chatter in FIL Slack
    • #ipfs-chatter:ipfs.io in Matrix
  • Add the link to the IPFS Discourse topic to the GitHub Release description
    • example
  • create an issue comment mentioning early testers on the release issue
    • example
  • create an issue comment linking to the release on the release issue
    • example
  • ask the marketing team to tweet about the release in #shared-pl-marketing-requests in FIL Slack
    • example
  • post the link to the GitHub Release to Reddit
    • example
• Test the new version with ipfs-companion (currently skipped)
  using ./kuboreleaser release --version vX.Y.Z(-rcN) test-ipfs-companion or ...

  • run the e2e
    • use vX.Y.Z(-RCN) as the Kubo image version
  • wait for the e2e workflow run to finish
• Update Kubo in ipfs-desktop
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop or ...

  • check out ipfs/ipfs-desktop
  • run npm install
  • create a PR which updates package.json and package-lock.json
  • add @SgtPooki as reviewer
• Update Kubo docs
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs or ...

  • run the update-on-new-ipfs-tag.yml workflow
  • merge the PR created by the update-on-new-ipfs-tag.yml workflow run
• Create a blog entry on blog.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-blog --date YYYY-MM-DD or ...

  • create a PR which adds a release note for the new Kubo version
    • example
  • merge the PR
  • verify the blog entry was published
• Merge the release branch back into master, ignoring the changes to version.go (keep the -dev) version,
  using ./kuboreleaser release --version vX.Y.Z(-rcN) merge-branch or ...

  • create a new branch merge-release-vX.Y.Z from release
  • create and merge a PR from merge-release-vX.Y.Z to master
• Prepare for the next release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) prepare-next or ...

  • Create the next changelog
  • Link to the new changelog in the CHANGELOG.md file
  • Create the next release issue
• Create a dependency update PR
  • check out ipfs/kubo
  • go over direct dependencies from go.mod in the root directory (NOTE: do not run go get -u as it will upgrade indirect dependencies which may cause problems)
  • run make mod_tidy
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[lidel]

Early testers ping for v0.32.0-rc1 testing ✨ If you have spare time, and don't have /ws listener enabled yet, give AutoTLS a try.

• Charity Engine (@Rytiss, @tristanolive)
• Fission (@bmann)
• Infura (@MichaelMure)
• OrbitDB (@haydenyoung)
• Pinata (@obo20)
• Shipyard (@cewood, @ns4plabs)
• Siderus (@koalalorenzo)
• Textile (@sanderpick)
• @RubenKelevra

You're getting this message because you're listed here. Please update this list if you no longer want to be included.

[lidel]

✅ Release Checklist (v0.32.0-rc2)

• Prepare the release branch and update version numbers accordingly
  using ./kuboreleaser --skip-check-before release --version vX.Y.Z(-rcN) prepare-branch or ...

  • create a new branch release-vX.Y.Z
    • use master as base if Z == 0
    • use release as base if Z > 0
  • update the CurrentVersionNumber in version.go in the master branch to vX.Y+1.0-dev
    • example
  • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-rcN)
    • example
  • create a draft PR from release-vX.Y to release
    • example
  • Cherry-pick commits from master to the release-vX.Y.Z using git cherry-pick -x <commit>
  • Add full changelog and contributors to the changelog
    • Replace the Changelog and Contributors sections of the changelog with the stdout of ./bin/mkreleaselog. Note that the command expects your $GOPATH/src/github.com/ipfs/kubo to include latest commits from release-vX.Y
      • do NOT copy the stderr
  • verify all CI checks on the PR from release-vX.Y to release are passing
  • Merge the PR from release-vX.Y to release 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 branch
• Create the release tag
  using ./kuboreleaser release --version vX.Y.Z(-rcN) tag or ...

  • This is a dangerous operation! Go and Docker publishing are difficult to reverse! Have the release reviewer verify all the commands marked with ⚠️!
  • ⚠️ tag the HEAD commit using git tag -s vX.Y.Z(-rcN) -m 'Prerelease X.Y.Z(-rcN)'
  • ⚠️ tag the HEAD commit of the release branch using git tag -s vX.Y.Z -m 'Release X.Y.Z'
  • ⚠️ verify the tag is signed and tied to the correct commit using git show vX.Y.Z(-rcN)
  • ⚠️ push the tag to GitHub using git push origin vX.Y.Z(-rcN)
    • do NOT use git push --tags because it pushes all your local tags
• Verify ipfs/distributions's .tool-versions's golang entry is set to the latest go release on the major go branch Kubo is being tested on (see go-version:).
• Publish to Dockerhub, NPM, and dist.ipfs.tech and GitHub using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-all or follow each step below:
  • Publish the release to DockerHub
    using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub or ...

    • Wait for Publish docker image workflow run initiated by the tag push to finish
    • verify the image is available on Docker Hub
  • Publish the release to dist.ipfs.tech
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

    • check out ipfs/distributions
    • create new branch: run git checkout -b release-kubo-X.Y.Z(-rcN)
    • run ./dist.sh add-version kubo vX.Y.Z(-rcN) to add the new version to the versions file
      • usage
    • create and merge the PR which updates dists/kubo/versions and dists/go-ipfs/versions ( and dists/kubo/current and dists/go-ipfs/current)
      • example
    • wait for the CI workflow run initiated by the merge to master to finish
    • verify the release is available on dist.ipfs.tech
  • Publish the release to NPM
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm (⚠️ you might need to run the command a couple of times because GHA might not be able to see the new distribution straight away due to caching) or ...

    • run the Release to npm workflow
    • check Release to npm workflow run logs to verify it discovered the new release
    • verify the release is available on NPM
  • Publish the release to GitHub
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-github or ...

    • create a new release on GitHub
      • RC example
      • FINAL example
      • use the vX.Y.Z(-rcN) tag
      • link to the release issue
      • link to the changelog in the description
      • check the This is a pre-release checkbox
      • copy the changelog (without the header) in the description
      • do NOT check the This is a pre-release checkbox
    • run the sync-release-assets workflow
    • wait for the sync-release-assets workflow run to finish
    • verify the release assets are present in the GitHub release
• Update Kubo staging environment, see the Running Kubo tests on staging for details.
  • Test last release against the current RC
  • Test last release against the current one
• Promote the release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

  • create an IPFS Discourse topic
    • prerelease example
    • release example
    • use Kubo vX.Y.Z(-rcN) 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 IPFS Discourse topic globally
    • you can make the topic a banner if there is no banner already
  • verify the IPFS Discourse topic was copied to:
    • #ipfs-chatter in IPFS Discord
    • #ipfs-chatter in FIL Slack
    • #ipfs-chatter:ipfs.io in Matrix
  • Add the link to the IPFS Discourse topic to the GitHub Release description
    • example
  • create an issue comment mentioning early testers on the release issue
    • example
  • create an issue comment linking to the release on the release issue
    • example
  • ask the marketing team to tweet about the release in #shared-pl-marketing-requests in FIL Slack
    • example
  • post the link to the GitHub Release to Reddit
    • example
• Test the new version with ipfs-companion (currently skipped)
  using ./kuboreleaser release --version vX.Y.Z(-rcN) test-ipfs-companion or ...

  • run the e2e
    • use vX.Y.Z(-rcN) as the Kubo image version
  • wait for the e2e workflow run to finish
• Update Kubo in ipfs-desktop
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop or ...

  • check out ipfs/ipfs-desktop
  • run npm install
  • create a PR which updates package.json and package-lock.json
  • add @SgtPooki as reviewer
• Update Kubo docs
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs or ...

  • run the update-on-new-ipfs-tag.yml workflow
  • merge the PR created by the update-on-new-ipfs-tag.yml workflow run
• Create a blog entry on blog.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-blog --date YYYY-MM-DD or ...

  • create a PR which adds a release note for the new Kubo version
    • example
  • merge the PR
  • verify the blog entry was published
• Merge the release branch back into master, ignoring the changes to version.go (keep the -dev) version,
  using ./kuboreleaser release --version vX.Y.Z(-rcN) merge-branch or ...

  • create a new branch merge-release-vX.Y.Z from release
  • create and merge a PR from merge-release-vX.Y.Z to master
• Prepare for the next release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) prepare-next or ...

  • Create the next changelog
  • Link to the new changelog in the CHANGELOG.md file
  • Create the next release issue
• Create a dependency update PR
  • check out ipfs/kubo
  • go over direct dependencies from go.mod in the root directory (NOTE: do not run go get -u as it will upgrade indirect dependencies which may cause problems)
  • run make mod_tidy
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[lidel]

0.32.0-rc2 is ready

[lidel]

✅ Release Checklist (v0.32.0)

• Prepare the release branch and update version numbers accordingly
  using ./kuboreleaser --skip-check-before release --version vX.Y.Z(-rcN) prepare-branch or ...

  • create a new branch release-vX.Y.Z
    • use master as base if Z == 0
    • use release as base if Z > 0
  • update the CurrentVersionNumber in version.go in the master branch to vX.Y+1.0-dev
    • example
  • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-rcN)
    • example
  • create a draft PR from release-vX.Y to release
    • example
  • Cherry-pick commits from master to the release-vX.Y.Z using git cherry-pick -x <commit>
  • Add full changelog and contributors to the changelog
    • Replace the Changelog and Contributors sections of the changelog with the stdout of ./bin/mkreleaselog. Note that the command expects your $GOPATH/src/github.com/ipfs/kubo to include latest commits from release-vX.Y
      • do NOT copy the stderr
  • verify all CI checks on the PR from release-vX.Y to release are passing
  • Merge the PR from release-vX.Y to release 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 branch
• Create the release tag
  using ./kuboreleaser release --version vX.Y.Z(-rcN) tag or ...

  • This is a dangerous operation! Go and Docker publishing are difficult to reverse! Have the release reviewer verify all the commands marked with ⚠️!
  • ⚠️ tag the HEAD commit using git tag -s vX.Y.Z(-rcN) -m 'Prerelease X.Y.Z(-rcN)'
  • ⚠️ tag the HEAD commit of the release branch using git tag -s vX.Y.Z -m 'Release X.Y.Z'
  • ⚠️ verify the tag is signed and tied to the correct commit using git show vX.Y.Z(-rcN)
  • ⚠️ push the tag to GitHub using git push origin vX.Y.Z(-rcN)
    • do NOT use git push --tags because it pushes all your local tags
• Verify ipfs/distributions's .tool-versions's golang entry is set to the latest go release on the major go branch Kubo is being tested on (see go-version:).
• Publish to Dockerhub, NPM, and dist.ipfs.tech and GitHub using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-all or follow each step below:
  • Publish the release to DockerHub
    using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub or ...

    • Wait for Publish docker image workflow run initiated by the tag push to finish
    • verify the image is available on Docker Hub
  • Publish the release to dist.ipfs.tech
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

    • check out ipfs/distributions
    • create new branch: run git checkout -b release-kubo-X.Y.Z(-rcN)
    • run ./dist.sh add-version kubo vX.Y.Z(-rcN) to add the new version to the versions file
      • usage
    • create and merge the PR which updates dists/kubo/versions and dists/go-ipfs/versions ( and dists/kubo/current and dists/go-ipfs/current)
      • example
    • wait for the CI workflow run initiated by the merge to master to finish
    • verify the release is available on dist.ipfs.tech
  • Publish the release to NPM
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm (⚠️ you might need to run the command a couple of times because GHA might not be able to see the new distribution straight away due to caching) or ...

    • run the Release to npm workflow
    • check Release to npm workflow run logs to verify it discovered the new release
    • verify the release is available on NPM
  • Publish the release to GitHub
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-github or ...

    • create a new release on GitHub
      • RC example
      • FINAL example
      • use the vX.Y.Z(-rcN) tag
      • link to the release issue
      • link to the changelog in the description
      • check the This is a pre-release checkbox
      • copy the changelog (without the header) in the description
      • do NOT check the This is a pre-release checkbox
    • run the sync-release-assets workflow
    • wait for the sync-release-assets workflow run to finish
    • verify the release assets are present in the GitHub release
• Update Kubo staging environment, see the Running Kubo tests on staging for details.
  • Test last release against the current RC
  • Test last release against the current one
• Promote the release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

  • create an IPFS Discourse topic
    • prerelease example
    • release example
    • use Kubo vX.Y.Z(-rcN) 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 IPFS Discourse topic globally
    • you can make the topic a banner if there is no banner already
  • verify the IPFS Discourse topic was copied to:
    • #ipfs-chatter in IPFS Discord
    • #ipfs-chatter in FIL Slack
    • #ipfs-chatter:ipfs.io in Matrix
  • Add the link to the IPFS Discourse topic to the GitHub Release description
    • example
  • create an issue comment mentioning early testers on the release issue
    • example
  • create an issue comment linking to the release on the release issue
    • example
  • ask the marketing team to tweet about the release in #shared-pl-marketing-requests in FIL Slack
    • example
  • post the link to the GitHub Release to Reddit
    • example
• Test the new version with ipfs-companion (currently skipped)
  using ./kuboreleaser release --version vX.Y.Z(-rcN) test-ipfs-companion or ...

  • run the e2e
    • use vX.Y.Z(-rcN) as the Kubo image version
  • wait for the e2e workflow run to finish
• Update Kubo in ipfs-desktop
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop or ...

  • check out ipfs/ipfs-desktop
  • run npm install
  • create a PR which updates package.json and package-lock.json
  • add @SgtPooki as reviewer
• Update Kubo docs
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs or ...

  • run the update-on-new-ipfs-tag.yml workflow
  • merge the PR created by the update-on-new-ipfs-tag.yml workflow run
• Create a blog entry on blog.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-blog --date YYYY-MM-DD or ...

  • create a PR which adds a release note for the new Kubo version
    • example
  • merge the PR
  • verify the blog entry was published
• Merge the release branch back into master, ignoring the changes to version.go (keep the -dev) version,
  using ./kuboreleaser release --version vX.Y.Z(-rcN) merge-branch or ...

  • create a new branch merge-release-vX.Y.Z from release
  • create and merge a PR from merge-release-vX.Y.Z to master
• Prepare for the next release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) prepare-next or ...

  • Create the next changelog
  • Link to the new changelog in the CHANGELOG.md file
  • Create the next release issue
• Create a dependency update PR
  • check out ipfs/kubo
  • go over direct dependencies from go.mod in the root directory (NOTE: do not run go get -u as it will upgrade indirect dependencies which may cause problems)
  • run make mod_tidy
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[lidel]

Kubo v0.32.0 is out!

[lidel]

Making patch with fix from #10581 (to restore accelerated dht client)

✅ Release Checklist v0.32.1

• Prepare the release branch and update version numbers accordingly
  using ./kuboreleaser --skip-check-before release --version vX.Y.Z(-rcN) prepare-branch or ...

  • create a new branch release-vX.Y.Z
    • use master as base if Z == 0
    • use release as base if Z > 0
  • update the CurrentVersionNumber in version.go in the master branch to vX.Y+1.0-dev
    • example
  • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-rcN)
    • example
  • create a draft PR from release-vX.Y to release
    • example
  • Cherry-pick commits from master to the release-vX.Y.Z using git cherry-pick -x <commit>
  • Add full changelog and contributors to the changelog
    • Replace the Changelog and Contributors sections of the changelog with the stdout of ./bin/mkreleaselog. Note that the command expects your $GOPATH/src/github.com/ipfs/kubo to include latest commits from release-vX.Y
      • do NOT copy the stderr
  • verify all CI checks on the PR from release-vX.Y to release are passing
  • Merge the PR from release-vX.Y to release 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 branch
• Create the release tag
  using ./kuboreleaser release --version vX.Y.Z(-rcN) tag or ...

  • This is a dangerous operation! Go and Docker publishing are difficult to reverse! Have the release reviewer verify all the commands marked with ⚠️!
  • ⚠️ tag the HEAD commit using git tag -s vX.Y.Z(-rcN) -m 'Prerelease X.Y.Z(-rcN)'
  • ⚠️ tag the HEAD commit of the release branch using git tag -s vX.Y.Z -m 'Release X.Y.Z'
  • ⚠️ verify the tag is signed and tied to the correct commit using git show vX.Y.Z(-rcN)
  • ⚠️ push the tag to GitHub using git push origin vX.Y.Z(-rcN)
    • do NOT use git push --tags because it pushes all your local tags
• Verify ipfs/distributions's .tool-versions's golang entry is set to the latest go release on the major go branch Kubo is being tested on (see go-version:).
• Publish to Dockerhub, NPM, and dist.ipfs.tech and GitHub using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-all or follow each step below:
  • Publish the release to DockerHub
    using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub or ...

    • Wait for Publish docker image workflow run initiated by the tag push to finish
    • verify the image is available on Docker Hub
  • Publish the release to dist.ipfs.tech
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

    • check out ipfs/distributions
    • create new branch: run git checkout -b release-kubo-X.Y.Z(-rcN)
    • run ./dist.sh add-version kubo vX.Y.Z(-rcN) to add the new version to the versions file
      • usage
    • create and merge the PR which updates dists/kubo/versions and dists/go-ipfs/versions ( and dists/kubo/current and dists/go-ipfs/current)
      • example
    • wait for the CI workflow run initiated by the merge to master to finish
    • verify the release is available on dist.ipfs.tech
  • Publish the release to NPM
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm (⚠️ you might need to run the command a couple of times because GHA might not be able to see the new distribution straight away due to caching) or ...

    • run the Release to npm workflow
    • check Release to npm workflow run logs to verify it discovered the new release
    • verify the release is available on NPM
  • Publish the release to GitHub
    using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-github or ...

    • create a new release on GitHub
      • RC example
      • FINAL example
      • use the vX.Y.Z(-rcN) tag
      • link to the release issue
      • link to the changelog in the description
      • check the This is a pre-release checkbox
      • copy the changelog (without the header) in the description
      • do NOT check the This is a pre-release checkbox
    • run the sync-release-assets workflow
    • wait for the sync-release-assets workflow run to finish
    • verify the release assets are present in the GitHub release
• Update Kubo staging environment, see the Running Kubo tests on staging for details.
  • Test last release against the current RC
  • Test last release against the current one
• Promote the release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

  • create an IPFS Discourse topic
    • prerelease example
    • release example
    • use Kubo vX.Y.Z(-rcN) 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 IPFS Discourse topic globally
    • you can make the topic a banner if there is no banner already
  • verify the IPFS Discourse topic was copied to:
    • #ipfs-chatter in IPFS Discord
    • #ipfs-chatter in FIL Slack
    • #ipfs-chatter:ipfs.io in Matrix
  • Add the link to the IPFS Discourse topic to the GitHub Release description
    • example
  • create an issue comment mentioning early testers on the release issue
    • example
  • create an issue comment linking to the release on the release issue
    • example
  • ask the marketing team to tweet about the release in #shared-pl-marketing-requests in FIL Slack
    • example
  • post the link to the GitHub Release to Reddit
    • example
• Test the new version with ipfs-companion (currently skipped)
  using ./kuboreleaser release --version vX.Y.Z(-rcN) test-ipfs-companion or ...

  • run the e2e
    • use vX.Y.Z(-rcN) as the Kubo image version
  • wait for the e2e workflow run to finish
• Update Kubo in ipfs-desktop
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop or ...

  • check out ipfs/ipfs-desktop
  • run npm install
  • create a PR which updates package.json and package-lock.json
  • add @SgtPooki as reviewer
• Update Kubo docs
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs or ...

  • run the update-on-new-ipfs-tag.yml workflow
  • merge the PR created by the update-on-new-ipfs-tag.yml workflow run
• Create a blog entry on blog.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-blog --date YYYY-MM-DD or ...

  • create a PR which adds a release note for the new Kubo version
    • example
  • merge the PR
  • verify the blog entry was published
• Merge the release branch back into master, ignoring the changes to version.go (keep the -dev) version,
  using ./kuboreleaser release --version vX.Y.Z(-rcN) merge-branch or ...

  • create a new branch merge-release-vX.Y.Z from release
  • create and merge a PR from merge-release-vX.Y.Z to master
• Prepare for the next release
  using ./kuboreleaser release --version vX.Y.Z(-rcN) prepare-next or ...

  • Create the next changelog
  • Link to the new changelog in the CHANGELOG.md file
  • Create the next release issue
• Create a dependency update PR
  • check out ipfs/kubo
  • go over direct dependencies from go.mod in the root directory (NOTE: do not run go get -u as it will upgrade indirect dependencies which may cause problems)
  • run make mod_tidy
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue