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.19.1 #9754

Closed
BigLep opened this issue Mar 25, 2023 · 7 comments
Closed

Release 0.19.1 #9754

BigLep opened this issue Mar 25, 2023 · 7 comments
Assignees

Comments

@BigLep
Copy link
Contributor

BigLep commented Mar 25, 2023

Meta

  • Release owner: @galargh
  • Release reviewer: @hacdias
  • Expected release date: 2023-03-27

See the Kubo release process for more info.

Purpose

  • Fix regressions identified in recent releases

Items in scope

✅ Release Checklist

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.

The release

This section covers tasks to be done during each release.

  • Prepare the release branch and update version numbers accordingly
    using kuboreleaser 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(-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 ...
  • Publish the release to 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.io
  • Publish the release to NPM
    using kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm 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
  • Promote the release
    using kuboreleaser release --version vX.Y.Z(-rcN) promote or ...
  • 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 interop
    using kuboreleaser release --version vX.Y.Z(-rcN) update-interop or ...
    • check out ipfs/interop
    • run npm install
    • create a PR which updates package.json and package-lock.json
    • merge the PR
  • Update Kubo in ipfs-desktop
    using kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop or ...
  • Update Kubo docs
    using kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs or ...
  • Create a blog entry on 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 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
@celeduc
Copy link

celeduc commented Mar 29, 2023

Also fixes #9705

@galargh
Copy link
Contributor

galargh commented Apr 3, 2023

PRs whose merges have to be cherry-picked to 0.19.1 release branch:

@Jorropo How did we get ipfs/boxo#232 to Kubo?

@galargh
Copy link
Contributor

galargh commented Apr 4, 2023

I cherry-picked the two changes I knew about to https://github.com/ipfs/kubo/tree/release-v0.19.1.

@Jorropo
Copy link
Contributor

Jorropo commented Apr 4, 2023

You can't backport ipfs/boxo#232 as-is.
Because we do not use boxo yet in v0.19.0, you need to backport ipfs/boxo@6f324be into https://github.com/ipfs/go-blockservice/ then release this new blockservice (patch release, no API was changed) finally update this in Kubo.

@BigLep
Copy link
Contributor Author

BigLep commented Apr 4, 2023

@Jorropo : are you saying we need this because it was a regression added with 0.19?

We're about to do a 0.20 RC this week, so I am worried that expanding scope on 0.19.1 is delaying it getting out. Also, if you believe the change needs to get out with 0.19.1, it would be helpful as the owner of the fix if you can get it ready since you have the most context on it.

@Jorropo
Copy link
Contributor

Jorropo commented Apr 4, 2023

@galargh I have backported the blockservice update onto the branch, you can go ahead with the release 🙂.

@galargh
Copy link
Contributor

galargh commented Apr 5, 2023

🎉 Kubo v0.19.1 is out!

@galargh galargh closed this as completed Apr 5, 2023
@galargh galargh unpinned this issue Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Archived in project
Development

No branches or pull requests

4 participants