libp2p
v0.42
🗺 What's left for release
- [x] https://github.com/libp2p/go-yamux/issues/129
- [x] Address comment in https://github.com/libp2p/go-libp2p/pull/3293#issuecomment-2913913207
- [X] https://github.com/libp2p/go-libp2p/issues/3265
- [ ]
<List of items with remaining PRs and/or Issues to be considered for this release>
Deferred
- [ ] https://github.com/libp2p/go-libp2p/pull/2950
🔦 Highlights
< top highlights for this release notes >
Changelog
< changelog generated by scripts/mkreleaselog >
✅ Release Checklist
- [ ] Stage 0 - Finishing Touches
- [ ] Go through relevant libp2p repos looking for unreleased changes that should make it into the release. If you find any, cut releases.
- [ ] Run
go get -u ./...to see if there are any out-of-date deps that look important. If there are, bubble them. Try to avoid directly updating indirect deps in go-libp2p'sgo.modwhen possible.
- [ ] Stage 1 - Release
- [ ] Publish the release through the GitHub UI, adding the release notes. Some users rely on this to receive notifications of new releases.
- [ ] Announce the release on the discuss.libp2p.io.
- [ ] Stage 2 - Update Upstream
- [ ] Update the examples to the final release
- [ ] Update the upstream dependencies to the final release and create PRs.
- [ ] filecoin-project/lotus
- [ ] go-libp2p-kad-dht
- [ ] go-libp2p-pubsub (In case of breaking changes.)
- [ ] ipfs/kubo
- [ ] Add new release to interop tester in test-plans
- [ ] Make required changes to the release process.
Waiting for https://github.com/quic-go/quic-go/pull/5220 to be included in a new quic-go release
Hi @galargh as @sukunrt mentioned, v0.42.0 is released but it's not marked as latest
https://github.com/libp2p/go-libp2p/releases/tag/v0.41.1 still has the latest tag
I marked 42 as latest manually but wondering if there's something wrong in the workflow (user error or automation)
Some questions upon reading the notes above:
Is the connection rate limiting also on localhost? i.e. running >16 peers in a single machine will mean they cannot connect to each others in the first 5 seconds? Are there error messages?
What facility is logging these errors?
Can limits be overriden via env var or anything different from recompiling an application that uses defaults?
Is the connection rate limiting also on localhost? i.e. running >16 peers in a single machine will mean they cannot connect to each others in the first 5 seconds? Are there error messages?
Localhost is exempt from these limits: https://github.com/libp2p/go-libp2p/blob/000582cf2c5864b406122d9cff46dd3b8b04abe3/p2p/host/resource-manager/conn_rate_limiter.go#L31
Are there error messages?
These are returned as errors that go through the same flow as any other connection error.
Can limits be overriden via env var or anything different from recompiling an application that uses defaults?
They can be changed WithConnRateLimiters. An application can define a env var to override these, but the library itself does not define or parse any env var to control these limits.
The defaults should be pretty safe. Please let us know if you have issues with them.
Hi @galargh as @sukunrt mentioned, v0.42.0 is released but it's not marked as
latesthttps://github.com/libp2p/go-libp2p/releases/tag/v0.41.1 still has thelatesttagI marked 42 as latest manually but wondering if there's something wrong in the workflow (user error or automation)
Thanks for the ping! I found the issue, we were considering the prereleases to be "newer" than the final releases when determining whether a release should be marked as latest or not. As a result, none of the final releases that had prereleases before were marked as latest. I fixed it now in https://github.com/ipdxco/unified-github-workflows/releases/tag/v1.0.27
