Release 0.25

[BigLep]

Meta

• Release owner: @hacdias
• Release reviewer: @Jorropo
• ✅ Expected RC date: 2023-12-06
• 🚢 Expected final release date: 2023-12-13
• Release PR: Release: v0.25.0 [skip changelog] #10246
• Accompanying PR for improving the release process: (example: docs: release process updates from v0.17.0 #9391)
• Accompanying Issue for updating the infra: (example: https://github.com/protocol/bifrost-infra/issues/2221)
• Changelog: https://github.com/ipfs/kubo/blob/master/docs/changelogs/v0.25.md

Items in scope

IPFS Shipyard Team (view)

Required

• feat: Opt-in API.HTTPAuthSecrets for securing Kubo RPC #10187
• fully remove mplex #10069
• remove experimental graphsync server #9747
• docs(cli): fix spelling #10240
• fix: allow daemon to start correctly if the API is null #10062 (needs to be cherry-picked)
• chore: bump to go-libp2p 0.32.2 #10254 (needs to be cherry-picked)

Optional / nice to have

• chore: webui v4.2.0 [skip changelog] #10241 with feat: updated dataset (2023-11-17) ipfs-shipyard/ipfs-geoip#112 (old dataset is 1 yr old) and fix for /webrtc* bug /webrtc-direct listener breaks Status page ipfs-webui#2176
• feat: ipfs key sign|verify #10235 (for offline key ownership proofs in Brave)
• Fuse functionality broken in v0.24.0 #10242 (broken since 0.24, but fuse is opt-in, so not a blocker, fine to push fix to 0.26)

[lidel]

@ipfs/gui-dev quick pulse check, do you think we could have ipfs-webui release with the two items listed above to include them in Kubo 0.25.0 RC1 on Dec 6th (~1.5 week from now), or should work on new webui be pushed to Kubo 0.26 and post-nucleation 2024 Q1?

[SgtPooki]

@lidel FYI that webui has been updated to use the latest multiformats library, along with ipld-explorer-components, and I will be releasing a new webui here shortly (waiting on ipfs/ipfs-webui#2181)

[SgtPooki]

you can test that the webui is working properly at https://dev.webui.ipfs.io right now:

[SgtPooki]

PR for new webui up at #10241

@lidel

[lidel]

• I think we are ready to go and do RC1, all items landed – @Jorropo feel free to start RC1 release dance sooner, if that works better for you (if not, fine t do it on 6th)
• I also think it is a good idea to do final release on Monday, given the Holiday break starts after 15th. Better to have a full week than 2 days if something goes wrong.

Thoughts?

[hacdias]

v0.25.0-rc1

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
• 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 and @whizzzkid as reviewers
• 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.25.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.

[hacdias]

I just fixed the test and merged #10062. We can maybe cherry-pick it for the final release.

[BigLep]

2023-12-12 maintainer conversation: we are planning to do the release 2023-12-13 after:

1. go-libp2p updated
2. Confirm Thunderdome results look good
   @Jorropo will do the release.

[Jorropo]

• 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
• 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 and @whizzzkid as reviewers
• 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