Deprecate across the board max_satisfaction_weight
#638
Conversation
|
Thanks for following through man. |
|
CI fails need you to use the new, non-deprecated versions, and there is some clippy stuff, could be unrelated to this PR but I didn't look. |
|
I'm on it... |
Adds a `since=10.0.0` to all `max_satisfaction_weight` deprecations. Adds a note telling users to check rust-bitcoin#476 for more details. Closes rust-bitcoin#637.
storopoli
force-pushed
the
js/deprecate-max_satisfaction
branch
from
b656b87
to
7fc7661
Compare
|
OK CI should pass now. I had to add some |
|
CI fail is unrelated to this PR. miniscript has MSRV of 1.48 still, that won't work when its dependencies are using 1.56.1 - that should have been changed before last release. |
|
FWIW the most thorough way to go about this is, IMO, to fix the clippy as a separate PR, fix the MSRV as a separate PR, then rebase this. I understand if you don't want to do all that, I can try get to it, likely won't be till next week though. |
I was tinkering with trying to get things to work with Rust 1.48.0. About the clippy warnings it seems also very easy. Don't worry we can hold this until I finish these tasks and rebase. |
Yep, go for it. Sorry that this hasn't been done already. I'm surprised we managed to update our |
Nothing out of the ordinary. The most alarming was the non-inclusive range in `test_utils.rs`. In some test functions I allowed myself to use `#[allow(clippy::type_complexity)]` because clippy was asking to create a type instead of using the big tuple. Since these were used just once, I thought it was overkill. Note, depends on: - rust-bitcoin#639 (we can also merge this into it instead of `master`) - rust-bitcoin#638 (has some allows on dead_code)
|
Ok PRs are up. Suggested order of merging:
Of course I'll need to rebase once an ancestor PR is merged... |
|
Honestly because these are independent (in terms of diff) and only affect the Github Actions CI (which we can't possibly bisect on) I'd be fine just merging them without them being rebased. But see my comment on your first one. |
Nothing out of the ordinary. The most alarming was the non-inclusive range in `test_utils.rs`. In some test functions I allowed myself to use `#[allow(clippy::type_complexity)]` because clippy was asking to create a type instead of using the big tuple. Since these were used just once, I thought it was overkill. Note, depends on: - rust-bitcoin#639 (we can also merge this into it instead of `master`) - rust-bitcoin#638 (has some allows on dead_code)
c301ce3 Update MSRV to 1.56.1 (Jose Storopoli) Pull request description: Following `rust-bitcoin` MSRV of 1.56.1, this pins MSRV to 1.56.1. Quoting a recent merge in `rust-bitcoin` > Rust version 1.56.0 introduced edition 2021. Shortly afterwards, on > October 21 2021 Rust version 1.56.1 was released. > > Debian stable is currently shipping `rustc 1.63.0`. > > Our stated MSRV policy is: In Debian stable and at least 2 years old. > > Therefore our MSRV policy is met by Rust version 1.56.1 and we can strat > to bump our MSRV org wide. > > Links: > - https://blog.rust-lang.org/2021/11/01/Rust-1.56.1.html > - https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html > - https://packages.debian.org/stable/rust/rustc Removing the pins in `contrib/test.sh` since they are not necessary in 1.56.1. EDIT: CI fails because of the `#[allow(dead_code)]` implemented in #638 on some Psbt traits. Do I port these to here? Conceptually they belong to #638 and not here. ACKs for top commit: apoelstra: ACK c301ce3 Tree-SHA512: 9dad92068d03a648e0d16e1bf0cba34a1959be981fbcec28bc3e6265b2c82df1380777b047e68c69ed80c579638a7e67738d3cec28293e7259abae3f348c3752
Nothing out of the ordinary. The most alarming was the non-inclusive range in `test_utils.rs`. In some test functions I allowed myself to use `#[allow(clippy::type_complexity)]` because clippy was asking to create a type instead of using the big tuple. Since these were used just once, I thought it was overkill. Note, depends on: - rust-bitcoin#639 (we can also merge this into it instead of `master`) - rust-bitcoin#638 (has some allows on dead_code)
e2636f3 Clippy lints MSRV 1.56.1 (Jose Storopoli) Pull request description: Nothing out of the ordinary. The most alarming was the non-inclusive range in `test_utils.rs`. In some test functions I allowed myself to use `#[allow(clippy::type_complexity)]` because clippy was asking to create a type instead of using the big tuple. Since these were used just once, I thought it was overkill. Note, depends on: - #639 (we can also merge this into it instead of `master`) - #638 (has some allows on dead_code) ACKs for top commit: apoelstra: ACK e2636f3 Tree-SHA512: d1f38d1e2a1415da816898806377c90986072fe0bc9a9dbc3e5476026c05c53743453cbd0a237a70aa27762f1be86e44c19422575b7e62f686140accc412177c
Adds a
since=10.0.0to allmax_satisfaction_weightdeprecations. Adds a note telling users to check #476 for more details.Closes #637.