Bump bdk_wallet version to 1.0.0-beta.3

[notmandatory]

Description

Bump bdk_wallet version to 1.0.0-beta.3

bdk_core to 0.1.1
bdk_chain to 0.18.1
bdk_bitcoind_rpc to 0.14.1
bdk_electrum to 0.17.1
bdk_esplora to 0.17.1
bdk_file_store to 0.15.1
bdk_testenv to 0.8.1

[evanlinjin]

bdk_core changes are technically non-breaking, would it make sense to bump to 0.1.1?

Also, couldn't we only bump the minor version of chain sources as well?

[notmandatory]

bdk_core changes are technically non-breaking, would it make sense to bump to 0.1.1?

If we know it's a non-breaking change then I agree it should only be a patch release bump. @ValuedMammal introduced me to the cargo-semver-check tool and we'll try using that for this and future releases to figure out how crates need to be bumped.

[ValuedMammal]

ACK 7a501c1

[evanlinjin]

I think bdk_chain contains breaking changes though due to Into<Arc<Transaction>>.

[notmandatory]

I think bdk_chain contains breaking changes though due to Into<Arc<Transaction>>.

The cargo-semver-checks tool said it was non-breaking, but it's possible we used the tool wrong or it was wrong. Let's see if we can figure that out between now and the next release OK?

[storopoli]

I can confirm that bdk_chain has a breaking change.
Running cargo check in a private codebase that depends on beta.2 while trying to update to beta.3 gives me:

Checking bdk_wallet v1.0.0-beta.3
error[E0308]: mismatched types
    --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bdk_wallet-1.0.0-beta.3/src/wallet/mod.rs:[11](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:12)00:54
     |
1098 |     pub fn insert_tx<T: Into<Arc<Transaction>>>(&mut self, tx: T) -> bool {
     |                      - found this type parameter
1099 |         let mut changeset = ChangeSet::default();
1100 |         changeset.merge(self.indexed_graph.insert_tx(tx).into());
     |                                            --------- ^^ expected `Transaction`, found type parameter `T`
     |                                            |
     |                                            arguments to this method are incorrect
     |
     = note:      expected struct `bitcoin::Transaction`
             found type parameter `T`
note: method defined here
    --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bdk_chain-0.18.0/src/indexed_tx_graph.rs:136:[12](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:13)
     |
136  |     pub fn insert_tx(&mut self, tx: Transaction) -> ChangeSet<A, I::ChangeSet> {
     |            ^^^^^^^^^

error[E0271]: type mismatch resolving `<impl IntoIterator<Item = (T, u64)> as IntoIterator>::Item == (&Transaction, u64)`
    --> /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba[15](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:16)001f/bdk_wallet-1.0.0-beta.3/src/wallet/mod.rs:2479:48
     |
2473 |     pub fn apply_unconfirmed_txs<T: Into<Arc<Transaction>>>(
     |                                  - found this type parameter
...
2479 |             .batch_insert_relevant_unconfirmed(unconfirmed_txs);
     |              --------------------------------- ^^^^^^^^^^^^^^^ expected `(&Transaction, u64)`, found `(T, u64)`
     |              |
     |              required by a bound introduced by this call
     |
     = note: expected tuple `(&bitcoin::Transaction, _)`
                found tuple `(T, _)`
note: required by a bound in `IndexedTxGraph::<A, I>::batch_insert_relevant_unconfirmed`
    --> /home/runner/.cargo/registry/src/index.crates.io-6f[17](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:18)d22bba15001f/bdk_chain-0.18.0/src/indexed_tx_graph.rs:206:44
     |
204  |     pub fn batch_insert_relevant_unconfirmed<'t>(
     |            --------------------------------- required by a bound in this associated function
[20](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:21)5  |         &mut self,
206  |         unconfirmed_txs: impl IntoIterator<Item = (&'t Transaction, u64)>,
     |                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `IndexedTxGraph::<A, I>::batch_insert_relevant_unconfirmed`

Some errors have detailed explanations: E0[27](https://github.com/alpenlabs/faucet-api/actions/runs/10853860821/job/30123056176#step:5:28)1, E0308.
For more information about an error, try `rustc --explain E0271`.
error: could not compile `bdk_wallet` (lib) due to 2 previous errors
Error: Process completed with exit code 101.

Sometimes cargo-semver-checks cannot give ALL possible breaking changes (see here),
but it is a good automated tool.

[notmandatory]

@storopoli oh shoot! does this happen even if you do a cargo update ? If so then I'll have to publish new versions 😞 .

[notmandatory]

I'm going to re-release a minor bump for all crates that have changes and yank the old versions.

[ValuedMammal]

Apologies for the version mistake

[notmandatory]

Apologies for the version mistake

Much better we try new things during the beta releases and figure out the issues now!

IMO the real issue is we need contributors who make breaking changes to figure out the the version bumping so we as release managers don't have to think about it. See my suggestion here: #1521 (comment)

[evanlinjin]

IMO the real issue is we need contributors who make breaking changes to figure out the the version bumping so we as release managers don't have to think about it. See my suggestion here: #1521 (comment)

Yes, commits that are breaking must include ! as stated in the Conventional Commits Specification. This already exists in our commit history, I think our commits been prudent to follow this.

I think the problem is with tooling. To figure out if a certain crate has breaking changes, we can iterate through the commit descriptions from the last release, find all commits with !, and the associated crates that are changed. A tool that can automatically do this will be great.

[evanlinjin]

I don't think we should rely on cargo-semver-checks (since it can't give all breaking changes as @storopoli stated). I think relying on ! in our commit history is the way to go. Reviewers should understand Crate Semvar Compatibility rules and make sure commit descriptions correctly mark changes as breaking/non-breaking.