You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our security fix policy for details.
🗺 What's left for release
We're pushing to do another release before the end of 2022 because:
< top highlights for this release notes. For ANY version (final or RCs) >
✅ Release Checklist
Checklist:
Stage 0 - Prerequisites
Open an issue against bifrost-infra ahead of the release (example). Idealy, do this multiple days in advance of the RC to give Bifrost the heads up that asks will be coming their way.
Spell out all that we want updated - gateways, the bootstraper and the cluster/preload nodes
Mention @protocol/bifrost-team in the issue and let them know the expected date of the release
Ensure that the What's left for release section has all the checkboxes checked. If that's not the case, discuss the open items with Kubo maintainers and update the release schedule accordingly.
Create docs-release-v0.18.0 branch, open a draft PR and keep updating docs/RELEASE_ISSUE_TEMPLATE.md on that branch as you go.
Ensure you have admin access to IPFS Discourse. Admin access is required to globally pin posts and create banners. @2color might be able to assist you.
Access to #bifrost channel in FIL Slack might come in handy. Ask the release reviewer to invite you over.
Access to #shared-pl-marketing-requests channel in FIL Slack will be required to request social shares. Ask the release reviewer to invite you over.
Skip filling out the ### Changelog section (the one where which lists all the commits and contributors) for now. We will populate it after the release branch is cut.
PR link:
Ensure the new changelog is linked in the CHANGELOG.md file.
Install ZSH (instructions). It is needed by the changelog creation script.
Ensure you have kubo checked out under $(go env GOPATH)/src/github.com/ipfs/kubo. This is required by the changelog creation script.
If you want your clone to live in a different location, you can symlink it 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.
Bump the version in version.go in the master branch to vX.(Y+1).0-dev via a PR (example).
Stage 2 - Release Candidate - if any non-trivial changes need to be included in the release, return to this stage
If it's not a first RC, add new commits to the release-v0.18.0 branch from master using git cherry-pick -x ...
Note: release-* branches are protected. You can do all needed updates on a separated branch (e.g. wip-release-v0.18.0) and when everything is settled push to release-v0.18.0
Bump the version in version.go in the release-v0.18.0 branch to v0.18.0-rcN.
If it's a first RC, create a draft PR targetting release branch if it doesn't exist yet (example).
Wait for CI to run and complete PR checks. All checks should pass.
Create a signed tag for the release candidate.
This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing. Remember to verify the commands you intend to run for items marked with ⚠️ with the release reviewer.
⚠️ Tag HEAD release-v0.18.0 commit with v0.18.0-rcN (git tag -s v0.18.0-rcN -m 'Pre-release 0.18.0-rcn')
Run git show v0.18.0-rcN to ensure the tag is correct.
⚠️ Push the v0.18.0-rcN tag to GitHub (git push origin v0.18.0-rcN; DO NOT USE git push --tags because it pushes all your local tags).
Run ./bin/mkreleaselog twice to generate the changelog and copy the output.
The first run of the script might be poluted with git clone output.
Paste the output into the ### Changelog section of the changelog file inside the <details><summary></summary></details> block.
Commit the changelog changes.
Push the release-v0.18.0 branch to GitHub (git push origin release-v0.18.0)
Mark the PR created from release-v0.18.0 as ready for review.
Ensure the PR is targetting release branch.
Ensure that CI is green.
Have release reviewer review the PR.
Merge the PR into release branch 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-v0.18.0 branch.
Checkout the release branch locally.
Remember to pull the latest changes.
Create a signed tag for the release.
This is a dangerous operation, as it is difficult to reverse due to Go modules and automated Docker image publishing. Remember to verify the commands you intend to run for items marked with ⚠️ with the release reviewer.
⚠️ Tag HEAD release commit with v0.18.0 (git tag -s v0.18.0 -m 'Release 0.18.0')
Run git show v0.18.0 to ensure the tag is correct.
⚠️ Push the v0.18.0 tag to GitHub (git push origin v0.18.0; DO NOT USE git push --tags because it pushes all your local tags).
Meta
2022-12-08week of 2022-12-122022-12-15week of 2022-12-192023-01See the Kubo release process for more info.
Kubo 0.18.0 Release
We're happy to announce Kubo 0.18.0!
As usual, this release includes important fixes, some of which may be critical for security. Unless the fix addresses a bug being exploited in the wild, the fix will not be called out in the release notes. Please make sure to update ASAP. See our security fix policy for details.
🗺 What's left for release
We're pushing to do another release before the end of 2022 because:
Project board: IPFS Shipyard Team (view)
Required before RC
fs-repo-12-to-13migrationfs-repo-12-to-13to dist.ipfs.techItems to during the RC phase before the final release
Nice to have
🔦 Highlights
< top highlights for this release notes. For ANY version (final or RCs) >
✅ Release Checklist
Checklist:
What's left for releasesection has all the checkboxes checked. If that's not the case, discuss the open items with Kubo maintainers and update the release schedule accordingly.docs-release-v0.18.0branch, open a draft PR and keep updatingdocs/RELEASE_ISSUE_TEMPLATE.mdon that branch as you go.### Changelogsection (the one where which lists all the commits and contributors) for now. We will populate it after the release branch is cut.kubochecked out under$(go env GOPATH)/src/github.com/ipfs/kubo. This is required by the changelog creation script.mkdir -p $(go env GOPATH)/src/github.com/ipfs && ln -s $(pwd) $(go env GOPATH)/src/github.com/ipfs/kubo.release-v0.18.0) frommaster.version.goin themasterbranch tovX.(Y+1).0-devvia a PR (example).release-v0.18.0branch frommasterusinggit cherry-pick -x ...release-*branches are protected. You can do all needed updates on a separated branch (e.g.wip-release-v0.18.0) and when everything is settled push torelease-v0.18.0version.goin therelease-v0.18.0branch tov0.18.0-rcN.releasebranch if it doesn't exist yet (example).release-v0.18.0commit withv0.18.0-rcN(git tag -s v0.18.0-rcN -m 'Pre-release 0.18.0-rcn')git show v0.18.0-rcNto ensure the tag is correct.v0.18.0-rcNtag to GitHub (git push origin v0.18.0-rcN; DO NOT USEgit push --tagsbecause it pushes all your local tags).ipfs/distributionsrepo locally.kubo-release-v0.18.0-rcn) frommaster../dist.sh add-version kubo v0.18.0-rcNto add the new version to theversionsfile (instructions).dist.shwill print WARNING: not marking pre-release kubo v0.18.0-rcN as the current version..kubo-release-v0.18.0-rcnbranch to GitHub and create a PR from that branch (example).masterbuild will publish the artifacts to https://dist.ipfs.io in around 30 minutesv0.18.0-rcNas the tag.This is a pre-release.Kubo v0.18.0-rcn Release Candidate is out!as the title.kuboandgo-ipfsas topics.##) in the description.npm installto updatepackage-lock.json.chromium --user-data-dir=$(mktemp -d)(macos/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=$(mktemp -d))firefox --profile $(mktemp -d)(macos/Applications/Firefox.app/Contents/MacOS/firefox --profile $(mktemp -d))releasebranch.version.goin therelease-v0.18.0branch to0.18.0../bin/mkreleaselogtwice to generate the changelog and copy the output.git cloneoutput.### Changelogsection of the changelog file inside the<details><summary></summary></details>block.release-v0.18.0branch to GitHub (git push origin release-v0.18.0)release-v0.18.0as ready for review.releasebranch.releasebranch using theCreate a merge commit(do NOT useSquash and mergenorRebase and mergebecause we need to be able to sign the merge commit).release-v0.18.0branch.releasebranch locally.releasecommit withv0.18.0(git tag -s v0.18.0 -m 'Release 0.18.0')git show v0.18.0to ensure the tag is correct.v0.18.0tag to GitHub (git push origin v0.18.0; DO NOT USEgit push --tagsbecause it pushes all your local tags).ipfs/distributionsrepo locally.kubo-release-v0.18.0) frommaster../dist.sh add-version kubo v0.18.0to add the new version to theversionsfile (instructions).kubo-release-v0.18.0branch to GitHub and create a PR from that branch (example).masterbuild will publish the artifacts to https://dist.ipfs.io in around 30 minutesv0.18.0as the tag.Kubo v0.18.0 Release is out!as the title.kuboandgo-ipfsas topics.##) in the description.releasebranch back intomaster, ignoring the changes toversion.go(keep the-devversion from master).How to contribute?
Would you like to contribute to the IPFS project and don't know how? Well, there are a few places you can get started:
help wantedlabel in the ipfs/kubo repo