Release 0.27

[hacdias]

Meta

• Release owner: @hacdias
• Release reviewer: TBD
• Expected RC1 date: week of 2024-02-19
• Expected RC2 date: week of 2024-03-01
• 🚢 Expected final release date: 2024-03-04
• Release PR: Release: v0.27.0 [skip changelog] #10344
• Thunderdome PR: chore: kubo-prerelease-27-rc1-by-2 probe-lab/thunderdome#113, chore: kubo-prerelease-27-rc2-by-2 probe-lab/thunderdome#115
• Accompanying PR for improving the release process: (example)
• Changelog: https://github.com/ipfs/kubo/blob/master/docs/changelogs/v0.27.md

Items In Scope

Required

• core/corehttp: wrap gateway with headers, deprecate gateway /api/v0 #10311
• core: deprecate CoreAPI.Dht, introduce CoreAPI.Routing #10329
• core/commands: remove 'ipfs dht' commands, except 'query' #10328
• fix(gw): negative entity-bytes beyond file size #10320
• Functional Thunderdome
  • 2024-02-08: it seems that Thunderdome is working properly, as long as the Kubo nodes run in io_large machines. This matches more or less the machines that the gateways themselves are running on.
• repo/fsrepo/migrations: verified HTTP migrations #10324

Nice To Have (Optional)

• feat: add Ipns.MaxCacheTTL #10321
• go-libp2p 0.33.0 , dropped support for Go 1.20

[lidel]

0.26 landed on Jan 22nd, since we try to do ~5 week intervals, I propose we aim at:

• RC date: week of 2024-02-19
• Final release date: 2024-02-27

[hacdias]

✅ Release Checklist (v0.27.0-rc1)

Labels

If an item should be executed for a specific release type, it should be labeled with one of the following labels:

• execute ONLY when releasing a Release Candidate
• execute ONLY when releasing a Final Release

Otherwise, it means it should be executed for ALL release types.

Patch releases should follow the same process as .0 releases. If some item should NOT be executed for a Patch Release, it should be labeled with:

• do NOT execute when releasing a Patch Release

Before the release

This section covers tasks to be done ahead of the release.

• Verify you have access to all the services and tools required for the release
  • GPG signature configured in local git and in GitHub
  • admin access to IPFS Discourse
    • ask the previous release owner (or @2color) for an invite
  • access to #shared-pl-marketing-requests channel in FIL Slack
    • ask the previous release owner for an invite
  • access to IPFS network metrics dashboards in Grafana
    • open an access request in the pldw
    • example
  • kuboreleaser checked out on your system (only if you're using kuboreleaser)
  • Thunderdome checked out on your system and configured (see the Thunderdome release docs for setup)
  • docker installed on your system (only if you're using kuboreleaser)
  • npm installed on your system (only if you're NOT using kuboreleaser)
  • zsh installed on your system
  • kubo checked out under $(go env GOPATH)/src/github.com/ipfs/kubo
    • you can also symlink your clone 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
  • Reddit account
• Upgrade Go used in CI to the latest patch release available in CircleCI in:
  • ipfs/distributions
    • example
  • ipfs/ipfs-docs
    • example
• Verify there is nothing left for release
• Create a release process improvement PR
  • update the release issue template as you go
  • link it in the Meta section

The release

This section covers tasks to be done during each release.

• 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
      • 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
• Run Thunderdome testing, see the Thunderdome release docs for details
  • create a PR and merge the experiment config into Thunderdome
• 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(-RCN) -m 'Release X.Y.Z(-RCN)'
  • ⚠️ 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
• 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
• 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 the release to dist.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

  • check out ipfs/distributions
  • 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_version and dists/go-ipfs/current_version)
    • example
  • wait for the CI workflow run initiated by the merge to master to finish
  • verify the release is available on dist.ipfs.io
• 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
• 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
  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
• Ask Brave to update Kubo in Brave Desktop
  • use this link to create an issue for the new Kubo version
    • basic example, example with additional notes
  • post link to the issue in #shared-pl-brave for visibility
• 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
  • run go get -u in root directory
  • run go mod tidy in root directory
  • run go mod tidy in docs/examples/kubo-as-a-library directory
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[hacdias]

Early testers ping for v0.27.0-rc1 testing 😄.

• Charity Engine (@Rytiss, @tristanolive)
• Fission (@bmann)
• Infura (@MichaelMure)
• OrbitDB (@aphelionz)
• pacman.store (@RubenKelevra)
• Pinata (@obo20)
• PL EngRes bifrost (@gmasgras)
• RTrade (@postables)
• Siderus (@koalalorenzo)
• Textile (@sanderpick)

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

[lidel]

Current plan is to do 0.27-rc2 on 2024-02-27 and push final release by one week to include a fix for regression described in ipfs-shipyard/nopfs#34.

We may also bump libp2p and try to aim for final release on 2024-03-04.

Part of the team is at ETH Denver, and we may delay if ipfs-shipyard/nopfs#34 proves to be a regression since 0.26 that blocks release. It there were bugs already present in 0.26, we should not block.

[hacdias]

✅ Release Checklist (v0.27.0-rc2)

Labels

If an item should be executed for a specific release type, it should be labeled with one of the following labels:

• execute ONLY when releasing a Release Candidate
• execute ONLY when releasing a Final Release

Otherwise, it means it should be executed for ALL release types.

Patch releases should follow the same process as .0 releases. If some item should NOT be executed for a Patch Release, it should be labeled with:

• do NOT execute when releasing a Patch Release

Before the release

This section covers tasks to be done ahead of the release.

• Verify you have access to all the services and tools required for the release
  • GPG signature configured in local git and in GitHub
  • admin access to IPFS Discourse
    • ask the previous release owner (or @2color) for an invite
  • access to #shared-pl-marketing-requests channel in FIL Slack
    • ask the previous release owner for an invite
  • access to IPFS network metrics dashboards in Grafana
    • open an access request in the pldw
    • example
  • kuboreleaser checked out on your system (only if you're using kuboreleaser)
  • Thunderdome checked out on your system and configured (see the Thunderdome release docs for setup)
  • docker installed on your system (only if you're using kuboreleaser)
  • npm installed on your system (only if you're NOT using kuboreleaser)
  • zsh installed on your system
  • kubo checked out under $(go env GOPATH)/src/github.com/ipfs/kubo
    • you can also symlink your clone 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
  • Reddit account
• Upgrade Go used in CI to the latest patch release available in CircleCI in:
  • ipfs/distributions
    • example
  • ipfs/ipfs-docs
    • example
• Verify there is nothing left for release
• Create a release process improvement PR
  • update the release issue template as you go
  • link it in the Meta section

The release

This section covers tasks to be done during each release.

• 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
      • 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
• Run Thunderdome testing, see the Thunderdome release docs for details
  • create a PR and merge the experiment config into Thunderdome
• 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(-RCN) -m 'Release X.Y.Z(-RCN)'
  • ⚠️ 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
• 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
• 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 the release to dist.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

  • check out ipfs/distributions
  • 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_version and dists/go-ipfs/current_version)
    • example
  • wait for the CI workflow run initiated by the merge to master to finish
  • verify the release is available on dist.ipfs.io
• 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
• 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
  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
• Ask Brave to update Kubo in Brave Desktop
  • use this link to create an issue for the new Kubo version
    • basic example, example with additional notes
  • post link to the issue in #shared-pl-brave for visibility
• 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
  • run go get -u in root directory
  • run go mod tidy in root directory
  • run go mod tidy in docs/examples/kubo-as-a-library directory
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[hacdias]

Early testers ping for v0.27.0-rc2 testing 😄.

• Charity Engine (@Rytiss, @tristanolive)
• Fission (@bmann)
• Infura (@MichaelMure)
• OrbitDB (@aphelionz)
• pacman.store (@RubenKelevra)
• Pinata (@obo20)
• PL EngRes bifrost (@gmasgras)
• RTrade (@postables)
• Siderus (@koalalorenzo)
• Textile (@sanderpick)

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

[hacdias]

✅ Release Checklist (v0.27.0)

This section covers tasks to be done during each release.

• 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
      • 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
• Run Thunderdome testing, see the Thunderdome release docs for details
  • create a PR and merge the experiment config into Thunderdome
• 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(-RCN) -m 'Release X.Y.Z(-RCN)'
  • ⚠️ 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
• 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
• 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 the release to dist.ipfs.tech
  using ./kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions or ...

  • check out ipfs/distributions
  • 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_version and dists/go-ipfs/current_version)
    • example
  • wait for the CI workflow run initiated by the merge to master to finish
  • verify the release is available on dist.ipfs.io
• 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
• 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
  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
• Ask Brave to update Kubo in Brave Desktop
  • use this link to create an issue for the new Kubo version
    • basic example, example with additional notes
  • post link to the issue in #shared-pl-brave for visibility
• 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
  • run go get -u in root directory
  • run go mod tidy in root directory
  • run go mod tidy in docs/examples/kubo-as-a-library directory
  • create a PR which updates go.mod and go.sum
  • add the PR to the next release milestone
• Close the release issue

[hacdias]

🎉 Kubo v0.27.0 is out!