-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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.21 #9814
Comments
The issue description has been updated with the updated set of items that are required for the 2023-06-01 RC. |
Issue description has been updated, but we should update to the latest go-libp2p (which is now go-libp2p 0.27.5, rather than 0.27.4). |
Concerning go-libp2p related releases... We're not going to depend on the upcoming go-libp2p 0.28 release. go-libp2p v0.28.0 will introduce smart dialling. Smart dialling prioritizes LAN addresses when possible so if you know about a LAN address of someone else, you will first ONLY try those. Unfortunately we announce LAN addresses in the DHT, so those dials habr to fail (or a timer has to expire) before we actually try the public IPs to avoid a performance hit on all connection to nodes that are not on your LAN. As a result, we need libp2p/go-libp2p-kad-dht#839 which removes the private IPs from the public DHT. However if we add libp2p/go-libp2p-kad-dht#839 we are breaking the cloud VPC usecase by removing the ability to use private IPs on the DHT. Arguably relying on private IPs over public DHT was a bug, so we should fix it by giving users control over their private DHT too with #9884. The Kubo release is already falling behind and I want to minimize the scope creep. We need to stick to the required items above. As a result, I think the actions are:
Cc @marten-seemann and @guillaumemichel so they're aware |
Update concerning the go-libp2p release per Slack thread... Kubo can update to go-libp2p 0.28 if it's ready since it won't incure extra work on the maintainers. This is because for go-libp2p 0.28 smart dialing local addresses and public addresses are dialed in parallel. For non-relay addresses, ranking and delaying dials happens within the address groups, not between address groups. It will not first dial localhost & LAN then public then relay. Instead go-libp2p v0.28 will first dial in parallel the best LAN, the best public v4 and the best public v6. There are docs about this in libp2p/go-libp2p#2336. If go-libp2p 0.28 is ready when we start the Kubo release, we'll pick it up. |
2023-06-08 maintainer conversation: we aren't going to do the RC until 2023-06-12 because we're waiting on libp2p/go-libp2p-kad-dht#820. Per that PR, we don't expect that to land until 2023-06-12. |
Early testers ping for v0.21.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. |
There has been some discussion amongst Kubo and go-libp2p maintainers on whether the 0.21 release should hold up for the recent 0.28 go-libp2p release. Kubo 0.21 with ship with go-libp2p 0.27.6 (not the newly release 0.28.0). Given that I held up the 0.21 release for other things, why won't I hold it up for a new go-libp2p? The Kubo release mostly slipped for the operational item fixes that we had discussed or drafted 3+ months ago (item 1, item 2). They had been spoken about for multiple months, and I didn't want to go into Q3 with those still open. They would have slipped to Q3 if 0.21 had shipped without them (since 0.22 won't happen until July). This is a judgement call, but for me it boils down to psychological, following through with public commitment to complete these changes by end of the quarter, and emphasizing that operational items are important (i.e., the train will depart to miss out on features, but we will cause disruption for security and operational items). I don't want to take on go-libp2p 0.28 right now because:
There is a lot of great functionality in go-libp2p 0.28, and I look forward it to landing in master/main soon and going out with Kubo 0.22, with a current RC targeting 2023-07-13. How close do Kubo maintainers hit their release dates? |
@hacdias : a couple of things about the release:
Thank you! |
Any chance we can get the latest webui in the this release? #9940 |
2023-06-13 maintainer conversation: Things for RC2:
|
libp2p go routine leak is being tracked here libp2p/go-libp2p-kad-dht#849 |
I believe the Thunderdome results will be published to https://www.notion.so/kubo-prerelease-21-93caf901a408490480438b48974d8a07 |
I updated the issue description with the items I believe need to make it into RC2:
In terms of timing, best case is we cut RC2 on 2023-06-14. We will need to do another round of Thunderdome testing. That doesn't look like that will happen until 2023-06-19, which leaves us with a best possible ship date of 2023-06-19 assuming no other problems found. |
The Kubo 0.21 release isn't done yet per above, but here was the status of the 0.21 iteration before prepping for 0.22: https://github.com/orgs/ipfs/projects/16/views/1?filterQuery=iteration%3A%22kubo+0.21%22
|
I forgot to save (doh!), but have done so now. |
Early testers ping for v0.21.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. |
In terms of release date, this will be 2023-06-19 at the earlier as need a successful thunderdome test run of RC2. I currently don't see one: https://protocollabs.grafana.net/d/GE2JD7ZVz/experiment-timeline?from=now-7d&to=now&var-experiment=kubo-prerelease-21&var-timeframe=6h&orgId=1 |
(I'm recalling more details. I believe there will be a RC3 with a new go-libp2p 0.27.x patchh release. We'd then Thunderdome test that and confirm results before release.). Please correct me if I have any of that wrong @Jorropo . |
Found a bug during RC2 testing, we need to include ipfs/boxo#358 in Kubo 0.21 (release blocker) |
Boxo patch release is up and Kubo is updated. |
Early testers ping for v0.21.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. |
In terms of next steps for completing the release, @Jorropo has confirmed in Thunderdome testing that goroutine leak and deadlock problems have been addressed. We now want to be confident that TTFB hasn't regressed. @Jorropo will capture his analysis in https://www.notion.so/pl-strflt/kubo-prerelease-21-93caf901a408490480438b48974d8a07. Once that is good, we'll release. We expect to do so by EOD Thursday, 2023-06-22, assuming no issues are found. Internal performance review work has reduced our bandwidth for getting this over the line quicker. |
2023-06-22 maintainer conversation:
|
Every Thunderdome experiment has a configured duration, specified in minutes in when |
@Jorropo : can you please provide an update on how your three things from the 2023-06-22 conversation are going? |
The fix for the migration and config issues are here #9995 |
Quick comment here that we will want to include some Boxo fixes in the 0.21:
I think it is safe to release a Boxo 0.11 (there were breaking changes in |
@BigLep What's the timeline for this release? The release timeline seems to be quite outdated:
|
@marten-seemann this week if Thunderdome testing results are good to go. |
Thank you @hacdias! |
From thunderdome testing all kubo rc4 are still running with no memory leak, they keep memory very cool (~6GiB) compared to v0.20 (has a memory leak ~32GiB then crashes). That a 🟢 on release for me on the thunderdom side. |
Release is scheduled for Monday |
🎉 Kubo v0.21.0 is out! |
The release is essentially done, so I'm closing 😄 There are still one or two things left that will be taken care async. |
Meta
2023-06-012023-06-082023-06-122023-06-082023-06-152023-07-04Items in scope
Required for RC1
dag import
error handling fixes fix(cmd): useful errors in dag import #9945moved to 0.22dag import
not pinning by default + regression tests feat!: dag import - don't pin roots by default #9926Required for RC2
Required for RC3
Others
These are items that we had stated at the beginning of the release that we said we wanted to include. We aren't blocking the relse on these. There are also items in 0.21 iteration.
ipfs pubsub
Commands #9717✅ Release Checklist
Labels
If an item should be executed for a specific release type, it should be labeled with one of the following labels:
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:Before the release
This section covers tasks to be done ahead of the release.
$(go env GOPATH)/src/github.com/ipfs/kubo
mkdir -p $(go env GOPATH)/src/github.com/ipfs && ln -s $(pwd) $(go env GOPATH)/src/github.com/ipfs/kubo
The release
This section covers tasks to be done during each release (current: 0.21.0)
using
kuboreleaser release --version vX.Y.Z(-rcN) prepare-branch
or ...release-vX.Y.Z
master
as base ifZ == 0
release
as base ifZ > 0
CurrentVersionNumber
in version.go in themaster
branch tovX.Y+1.0-dev
CurrentVersionNumber
in version.go in therelease-vX.Y
branch tovX.Y.Z(-RCN)
release-vX.Y
torelease
master
to therelease-vX.Y.Z
usinggit cherry-pick -x <commit>
Changelog
andContributors
sections of the changelog with the stdout of./bin/mkreleaselog
release-vX.Y
torelease
are passingrelease-vX.Y
torelease
using theCreate a merge commit
Squash and merge
norRebase and merge
because we need to be able to sign the merge commitrelease-vX.Y
branchusing
kuboreleaser release --version vX.Y.Z(-rcN) tag
or ...git tag -s vX.Y.Z(-RCN) -m 'Prerelease X.Y.Z(-RCN)'
release
branch usinggit tag -s vX.Y.Z(-RCN) -m 'Release X.Y.Z(-RCN)'
git show vX.Y.Z(-RCN)
git push origin vX.Y.Z(-RCN)
git push --tags
because it pushes all your local tagsusing
kuboreleaser --skip-check-before --skip-run release --version vX.Y.Z(-rcN) publish-to-dockerhub
or ...using
kuboreleaser release --version vX.Y.Z(-rcN) publish-to-distributions
or ..../dist.sh add-version kubo vX.Y.Z(-RCN)
to add the new version to theversions
filedists/kubo/versions
anddists/go-ipfs/versions
( anddists/kubo/current_version
anddists/go-ipfs/current_version
)using
kuboreleaser release --version vX.Y.Z(-rcN) publish-to-npm
or ...using
kuboreleaser release --version vX.Y.Z(-rcN) publish-to-github
or ...vX.Y.Z(-RCN)
tagThis is a pre-release
checkboxThis is a pre-release
checkboxusing
kuboreleaser release --version vX.Y.Z(-rcN) promote
or ...Kubo vX.Y.Z(-RCN) is out!
as the titlekubo
andgo-ipfs
as topics##
) in the descriptionipfs-companion
using
kuboreleaser release --version vX.Y.Z(-rcN) test-ipfs-companion
or ...vX.Y.Z(-RCN)
as the Kubo image versionusing
kuboreleaser release --version vX.Y.Z(-rcN) update-interop
or ...npm install
package.json
andpackage-lock.json
using
kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-desktop
or ...npm install
package.json
andpackage-lock.json
using
kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-docs
or ...using
kuboreleaser release --version vX.Y.Z(-rcN) update-ipfs-blog --date YYYY-MM-DD
or ...-dev
) version,using
kuboreleaser release --version vX.Y.Z(-rcN) merge-branch
or ...merge-release-vX.Y.Z
fromrelease
merge-release-vX.Y.Z
tomaster
using
kuboreleaser release --version vX.Y.Z(-rcN) prepare-next
or ...go get -u
in root directorygo mod tidy
in root directorygo mod tidy
indocs/examples/kubo-as-a-library
directorygo.mod
andgo.sum
The text was updated successfully, but these errors were encountered: