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
New web/nodejs specific targets may be added, which will warrant deprecation of out-of-box support of wasm32-unknown-unknown target. See: New targets rustwasm/team#38
Following those changes may cause getrandom build breakage for some users, e.g. even if we'll write stdweb = ["wasm-indgen"] in Cargo.toml it may break build for users of older stdweb versions. Thus I believe we should think about how those changes can be handled in future.
I see 3 options:
Publish v0.2 on each deprecation, it's the most conservative option, but will cause a great deal of churn, because we will have to do breaking releases for downstream rand crates.
State that both WASM features are experimental and not covered by backward compatibility promise.
Currently for
wasm32-unknown-unknowntarget we have two featuresstdwebandwasm-bindgen. In future the following changes can happen:stdwebwill become compatible withwasm-bindgen, which will allow us to deprecatestdwebfeature. See: Building on top of wasm-bindgen? koute/stdweb#318wasm32-unknown-unknowntarget. See: New targets rustwasm/team#38Following those changes may cause
getrandombuild breakage for some users, e.g. even if we'll writestdweb = ["wasm-indgen"]inCargo.tomlit may break build for users of olderstdwebversions. Thus I believe we should think about how those changes can be handled in future.I see 3 options:
randcrates.cc @koute @alexcrichton