What is our policy for tracking the Cargo.lock file?

[ValuedMammal]

Some alternatives

1. Untrack the Cargo.lock file from version control, as is common in other BDK projects
2. If we decide to track the lock file, consider adopting a minimal/recent strategy similar to rust-bitcoin
   2a. Have a policy for how and when the lock file is updated. Consider using rust-bitcoin-maintainer-tools.

[oleonardolima]

At least as a first opinion I'd go with (1) to stick with the same policy as the rest of the orgs projects, though we should probably take this opportunity to discuss it further.

[tvpeter]

I'm also of the opinion that we should not track the Cargo.lock file, as this is not a binary crate and it does not offer any immediate advantage.

[luisschwab]

We should use cargo-rbmt and commit Cargo-recent.lock and Cargo-minimal.lock in the same manner as rust-bitcoin. It also makes local/CI testing a lot easier.

[luisschwab]

We should use cargo-rbmt and commit Cargo-recent.lock and Cargo-minimal.lock in the same manner as rust-bitcoin. It also makes local/CI testing a lot easier.

I'll tackle this one.