feat(swarm): rename NetworkBehaviourAction to ToSwarm#3658
feat(swarm): rename NetworkBehaviourAction to ToSwarm#3658mergify[bot] merged 5 commits intomasterfrom
NetworkBehaviourAction to ToSwarm#3658Conversation
mxinden
left a comment
There was a problem hiding this comment.
No need to bump the other crates in my eyes.
| use libp2p_swarm::{ | ||
| dummy, CloseConnection, ConnectionDenied, ConnectionId, FromSwarm, NetworkBehaviour, | ||
| NetworkBehaviourAction, PollParameters, THandler, THandlerInEvent, THandlerOutEvent, | ||
| PollParameters, THandler, THandlerInEvent, THandlerOutEvent, ToSwarm, |
There was a problem hiding this comment.
With this change libp2p-allow-block-list depends on libp2p-swarm >=0.42.1, but its Cargo.toml allows libp2p-swarm v0.42.0.
I don't think this is a pressing issue, thus not sure whether to release a patch release of libp2p-allow-block-list with the above restriction. What do you think @thomaseizinger?
The same applies to other crates below that we have released since.
There was a problem hiding this comment.
Right, it is an issue. We should have bumped the dependency version but not the version of each dependent crate.
I'll send a fix.
Can we mitigate this with an automated check somehow? Perhaps -Z minimal-versions helps?
There was a problem hiding this comment.
Can we mitigate this with an automated check somehow? Perhaps
-Z minimal-versionshelps?
I think I found a solution: #3715
With #3658, these crates depend on the `0.42.1` release to access the new `ToSwarm` type. With the currently specified version, a user could theoretically run into a compile error if they pin `libp2p-swarm` to `0.42.0` in their lockfile but update to the latest patch release of one of these crates. Pull-Request: #3711.
Previously, we would specify the version and path of our workspace dependencies in each of our crates. This is error prone as #3658 (comment) for example shows. Problems like these happened in the past too. There is no need for us to ever depend on a earlier version than the most current one in our crates. It thus makes sense that we manage this version in a single place. Cargo supports a feature called "workspace inheritance" which allows us to share a dependency declaration across a workspace and inherit it with `{ workspace = true }`. We do this for all our workspace dependencies and for the MSRV. Resolves #3787. Pull-Request: #3715.
Resolves libp2p#3123. Pull-Request: libp2p#3658.
With libp2p#3658, these crates depend on the `0.42.1` release to access the new `ToSwarm` type. With the currently specified version, a user could theoretically run into a compile error if they pin `libp2p-swarm` to `0.42.0` in their lockfile but update to the latest patch release of one of these crates. Pull-Request: libp2p#3711.
Previously, we would specify the version and path of our workspace dependencies in each of our crates. This is error prone as libp2p#3658 (comment) for example shows. Problems like these happened in the past too. There is no need for us to ever depend on a earlier version than the most current one in our crates. It thus makes sense that we manage this version in a single place. Cargo supports a feature called "workspace inheritance" which allows us to share a dependency declaration across a workspace and inherit it with `{ workspace = true }`. We do this for all our workspace dependencies and for the MSRV. Resolves libp2p#3787. Pull-Request: libp2p#3715.
Description
Resolves #3123.
Notes & open questions
Do we need to bump the versions of all dependents here? It is backwards-compatible, meaning we can patch-release
libp2p-swarmand all dependencies should still be working, even if the new version is pulled in.Change checklist