Remove Cargo.lock?

[Kixunil]

Cargo.lock is normally not supposed to be committed (it' ignored in binaries anyway), is there a specific reason to keep it?

[dr-orlovsky]

Yes: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

We had multiple problems with the fact that some crates to not follow (in fact) semantic versioning and can break package from being compiled in a random fashion. So most of rust-bitcoin related projects having this issues in the past start to commit to Carto.lock

[Kixunil]

This is an interesting problem because the lock is still ignored by binaries which are the consumers of API. The API promises MSRV, but the dependencies don't. So any user of the API still has to manually specify versions. You could pin them in Cargo.toml but then the users of newer compiler can't benefit from updates to those dependencies.

But maybe I have a solution. It's possible to conditionally add dependencies (example in my recent crate), features are supported as well. So the solution would be to have a feature new_rust and then conditionally pin the dependencies in Cargo.toml depending on whether that feature is active. (Rust version would be an even better condition, but it seems to be impossible.)

What do you think?

[dr-orlovsky]

Well, we use conditional dependencies. In general I have to say that dependency version management becomes a nightmare for libraries and I do not know any good solution to that...

[Kixunil]

Currently conditional dependencies are used just to activate features. I was suggesting using them for selecting versions of dependencies. if dependency x works on version 1.2.3 and doesn't on 1.2.4, then we can make the requirement =1.2.3 by default and change it to 1.2.4 when new_rust is activated.