What does it mean for rust-bitcoin to be feature complete

[tcharding]

We have a stabilization issue for rust-bitcoin. The biggest blocker is rust-secp256k1 not being stable, and the blocker to this, IIUC, is that libsecp256k1 does not do releases (I don't actually know how the secp C code got into depend/secp256k1 or where, which commit, it was taken from).

The next major task after v0.29.0 release is to start crate smashing. And as we smash each crate it would be nice if we could push them towards v1.0.0

There is a stabilization issue for bech32, which is a candidate for the first of our crates to get to v1.0.0

Can we come up with a path to v1.0.0 for rust-bitcoin? Can we come up with a definition of feature complete?

[apoelstra]

In my view

• rust-secp, bitcoin_hashes, rust-bech32 etc being stable (for rust-secp this may require libsecp to stabilize, not sure..)
• Done PSBT2, for whatever notion of "done" the PSBT people think makes sense
• Done API overhaul Rearrange all the modules #525 (or whatever)
• Done crate smashing

[Kixunil]

For me in addition to what @apoelstra wrote:

• All open issues marked 1.0 are resolved
• all APIs are Rust-idiomatic
• commit to some defined invariants for each type
• squeeze as much protection from the type system as we can
• if there are any API changes that improve performance (without sacrificing security by default) do them

I'd want the crate quality to be comparable to std/serde/... (yes, a very high bar).

[tcharding]

I'd want the crate quality to be comparable to std/serde/... (yes, a very high bar).

I'm down with this, lets go!

[Kixunil]

One more: no API breaking change needed for an extended period of time (1 year?).

[sanket1729]

I don't know what's the progress on static contexts in libsecp land. But it would really nice if we can use static contexts to clean up all the APIs that require the &secp parameter floating around.