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 think this is backwards coupling - it should be up to the consumer of the environment variable (wherever that is) to decide what they're interested in, and when to rebuild.
Ultimately, they should be running cargo metadata etc - this logic shouldn't live in our repo unless they're outside of the cargo build.
The text was updated successfully, but these errors were encountered:
I think this is backwards coupling - it should be up to the consumer of the environment variable (wherever that is) to decide what they're interested in, and when to rebuild.
I suppose so... But EVM_ARITHMETIZATION_PACKAGE_VERSION really is just intended for zero_bin only right? I guess using the patch version is technically safer in case someone increments the patch version when they should have incremented minor/major, but at the same time, the only fix they would need to do is just regenerate their circuits.
My slight personal preference would be to ignore patch, but I'm honestly good either way.
zk_evm/zero_bin/leader/build.rs
Lines 12 to 17 in d02e150
We censor the minor version, and drop the pre-release and build meta.
This is why we do this:
@Nashtare in review comment
I think this is backwards coupling - it should be up to the consumer of the environment variable (wherever that is) to decide what they're interested in, and when to rebuild.
Ultimately, they should be running
cargo metadata
etc - this logic shouldn't live in our repo unless they're outside of the cargo build.The text was updated successfully, but these errors were encountered: