Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 0.30 #10436

Closed
31 of 32 tasks
lidel opened this issue May 28, 2024 · 18 comments
Closed
31 of 32 tasks

Release 0.30 #10436

lidel opened this issue May 28, 2024 · 18 comments
Assignees
Labels
effort/weeks Estimated to take multiple weeks P1 High: Likely tackled by core team if no one steps up topic/release Topic release

Comments

@lidel
Copy link
Member

lidel commented May 28, 2024

Meta

Items In Scope

Required

Nice To Have (Optional)

@lidel
Copy link
Member Author

lidel commented Aug 14, 2024

We've found a potential regression in go-libp2p-kad-dht and RC1 will be slightly delayed until we have a fix.
In the meantime, working on Support for UnixFS 1.5 Mode and ModTime and hoping to include it in RC1 as well.

@lidel
Copy link
Member Author

lidel commented Aug 21, 2024

go-libp2p-kad-dht regression should be fixed by dependency update made in #10488.

Release dance for 0.30.0-rc1 is unblocked.

@lidel
Copy link
Member Author

lidel commented Aug 21, 2024

✅ Release Checklist (v0.30.0-rc1)

  • 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
    • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-RCN)
    • create a draft PR from release-vX.Y to release
    • 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
  • 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
  • Publish the release to DockerHub
    using ./kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub or ...
  • 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
    • 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)
    • 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 ...
  • 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
  • Run Thunderdome testing, see the Thunderdome release docs for details
    • create a PR and merge the experiment config into Thunderdome
  • Promote the release
    using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...
  • 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 ...
  • 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
    • 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 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
Copy link
Member Author

lidel commented Aug 22, 2024

@lidel
Copy link
Member Author

lidel commented Aug 22, 2024

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

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

@2color
Copy link
Member

2color commented Aug 22, 2024

@lidel I'm working with @sukunrt now on a fix for libp2p/go-libp2p#2913. There's a good chance we'll have a release by EOD once Marco can take a look. Can we hold off the final release?

@lidel
Copy link
Member Author

lidel commented Aug 22, 2024

@2color yes, I already planned to have -rc2 next week if we land some fixes, so no problem to wait.

Update: after analysis, the go-libp2p fix from libp2p/go-libp2p#2936 is not a blocker, because majority of users uses static ports, and the problem only occurs in test environments when 0 is used and different UDP port is used for QUIC and Webtransport. We will cut RC2 without waiting for new libp2p.

@lidel
Copy link
Member Author

lidel commented Aug 28, 2024

✅ Release Checklist (v0.30.0-rc2)

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
    • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-RCN)
    • create a draft PR from release-vX.Y to release
    • 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
  • 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
  • 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 ...
    • 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
      • 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)
      • 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 ...
    • 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
  • Run Thunderdome testing, see the Thunderdome release docs for details
    • create a PR and merge the experiment config into Thunderdome
  • Promote the release
    using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

@lidel
Copy link
Member Author

lidel commented Aug 28, 2024

Early testers ping for v0.30.0-rc2 testing ✨

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

@lidel
Copy link
Member Author

lidel commented Aug 31, 2024

FYSA found a regression caused by go1.23 update: #10501
Workaround is to run with GODEBUG=asynctimerchan=1.
We will likely switch to go1.22 before final release.

@2color
Copy link
Member

2color commented Sep 3, 2024

Given that go-libp2p hasn't been updated to account for libp2p/specs#628, WebRTC-direct won't work out of the box.

Browser users (js-libp2p, Helia and verified-fetch) would have to override the default maxMessageSize when initialising the transport in js-libp2p WebRTC-direct, for browser <---webrtc-direct > to work.

@lidel
Copy link
Member Author

lidel commented Sep 3, 2024

Ack, I see it is still being discussed, so tentatively planing to cut 0.30.0-rc3 ~Thu? if/once we agree the maxMessageSize has to change.

@2color
Copy link
Member

2color commented Sep 5, 2024

The WebRTC maxMessageSize change has been reverted in js-libp2p, so it's no longer a blocker.

@lidel
Copy link
Member Author

lidel commented Sep 5, 2024

In the meantime we had boxo and go-libp2p releases with various fixes, and we had to switch back to go1.22 (#10502), so making 0.30.0-rc3 still feels prudent.

Plan is to have final 0.30 next week.

@lidel
Copy link
Member Author

lidel commented Sep 5, 2024

✅ Release Checklist (v0.30.0-rc3)

  • 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
    • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-RCN)
    • create a draft PR from release-vX.Y to release
    • 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
  • 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 ...
    • 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
      • 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)
      • 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 ...
    • 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
  • Run Thunderdome testing, see the Thunderdome release docs for details
  • Promote the release
    using ./kuboreleaser release --version vX.Y.Z(-rcN) promote or ...

@lidel
Copy link
Member Author

lidel commented Sep 5, 2024

Early testers ping for v0.30.0-rc3 testing ✨

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

@lidel
Copy link
Member Author

lidel commented Sep 11, 2024

✅ Release Checklist (v0.30.0) [FINAL]

  • 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
    • update the CurrentVersionNumber in version.go in the release-vX.Y branch to vX.Y.Z(-RCN)
    • create a draft PR from release-vX.Y to release
    • 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
  • 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 ...
    • 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
      • 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)
      • 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 ...
    • 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 ...
  • 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 ...
  • 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
    • 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 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
Copy link
Member Author

lidel commented Sep 11, 2024

🎉 Kubo v0.30.0 is out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/weeks Estimated to take multiple weeks P1 High: Likely tackled by core team if no one steps up topic/release Topic release
Projects
None yet
Development

No branches or pull requests

2 participants