Closed hdevalence closed 4 years ago
I've also bumped criterion dependency to 0.3 - seems like it's compatible with our benchmarks. So it uses the same rand
as the rest of the code. Otherwise we'd have 3 different versions of rand
in benchmark builds.
Yay!
I guess the only thing to remember is that when we do a 2.0 release we should be sure to disable the yoloproofs
feature again in the published crate.
I guess the only thing to remember is that when we do a 2.0 release we should be sure to disable the yoloproofs feature again in the published crate.
is it done manually somehow?
Yeah, last time the workflow was (assuming main
, develop
are in sync with the repo):
develop
to release/X.Y.Z
release
branch, comment out yoloproofs
in the Cargo.toml
in a single atomic commitX.Y.Z
, checkout the tag, cargo publish
release/X.Y.Z
into main
main
into develop
develop
, do a revert of the atomic commit from (2).main
, develop
, and the X.Y.Z
tag to the repo.if CI is so damn clever to check rustfmt, can't just do it all by itself, check that tests work and offer you a one-click green-checkmark commit button without waiting for the tests to run all over again
maybe in a couple of months we'll be able to get CI finish in green
I tried manually restarting the build.
The build timed out again, but running the command locally passes. My preference would be to merge this and try to fix the CI later, does that sound good?
Yup!
Done!
This is a breaking API change that will require a
2.0.0
version, but it keeps the crate up-to-date with the rand ecosystem. A possible further simplification of the dep tree would be to replaceclear_on_drop
byzeroize
, but this could be done at any later point becauseclear_on_drop
is an implementation detail.