v0.34

[p-shahi]

🗺 What's left for release

ETA: 2024-04-30

• [x] #2696 (If this is included, let's call out any breaking changes)
• [x] #1917
• [ ] #2614
• [x] https://github.com/pion/dtls/pull/628
• [x] https://github.com/pion/webrtc/issues/2672
• [x] https://github.com/libp2p/go-libp2p/issues/2754
• [x] #2787

🔦 Highlights

WebRTC Direct

• We've significantly improved support for webrtc-direct transport with multiple security and performance fixes.
• Based on the experience of webrtc-direct on v0.34 we intend to make it non experimental in v0.35

Transient Connections are now called Limited Connections

• Connections to peers over relayed or other limited connections, previously called transient are now called limited throughout the code. Limited is more descriptive of the connection's behavior and it avoids conflict with Resource Manager's Transient scope.
• For Connections, the Transient connection state has been renamed to Limited. This is a breaking change and you'll have to replace uses of conn.Stat().Transient with conn.Stat().Limited
• Network context functions like network.WithUseTransient are deprecated, use their limited alternatives like network.WithUseLimited.

Limited Connectedness state

• Peers connected to the host via relayed or any other limited connection now report their connectivity state as Limited.
• This state is also reflected in EvtPeerConnectednessChanged event. Consumers only interested in peers connected over Unlimited connections can ignore events with Limited Connectedness. NOTE: This changes the behavior of the Connected Connectedness state. Previously it included all limited connections and now it doesn't. To keep existing behavior in your code you can replace checks connectedness == network.Connected with connectedness != network.NotConnected

⚠️ Breaking Changes ⚠️

1. Transient Connections are now called Limited Connections. The prior terminology was confusing to many, and conflicted with the transient definition in the resource manager. The term actually referred to a connection that was relayed and limited in some aspect (either data or time).
2. libp2phttp: The well-known resource for libp2p protocols has changed. See the discussion thread for context. This means that new clients will not be able to reach the well-known endpoint automatically on old servers, and new servers won't respond to the old well-known endpoint to old clients. If you do not fully control the deployment of this, you should set EnableCompatibilityWithLegacyWellKnownEndpoint in libp2phttp.Host to true to enable backwards compatibility. This is not the default behavior because libp2phttp is still experimental and things are generally permitted to break. In this case supporting backwards compatibility was simple enough and we generally don't like breaking users even on an experimental feature.

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's go.mod when 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.