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
I just bumped our dependency on shadowsocks by just doing cargo update -p shadowsocks. This sticks to semver compatible releases (1.14 -> 1.15 in this case). But then my code stopped compiling. Because we were using shadowsocks::crypto::v1::CipherKind, a type that no longer existed.
This is because shadowsocks publicly re-exports shadowsocks-crypto, the API for shadowsocks-crypto changed in a semver breaking way.
I like the convenience of having shadowsocks-crypto re-exported directly from shadowsocks. But also, shadowsocks-crypto is a 0.x release and shadowsocks is at 1.y. It's probably not ideal to publicly re-export an "unstable" crate in the public API of a stable crate.
I just bumped our dependency on
shadowsocks
by just doingcargo update -p shadowsocks
. This sticks to semver compatible releases (1.14 -> 1.15 in this case). But then my code stopped compiling. Because we were usingshadowsocks::crypto::v1::CipherKind
, a type that no longer existed.This is because
shadowsocks
publicly re-exportsshadowsocks-crypto
, the API forshadowsocks-crypto
changed in a semver breaking way.I like the convenience of having
shadowsocks-crypto
re-exported directly fromshadowsocks
. But also,shadowsocks-crypto
is a0.x
release andshadowsocks
is at1.y
. It's probably not ideal to publicly re-export an "unstable" crate in the public API of a stable crate.You could potentially try out semver checking software before a release, to check if you did not break the API. Such as https://crates.io/crates/cargo-semver-checks or https://crates.io/crates/semverver.
The text was updated successfully, but these errors were encountered: