Please don't stabilize this crate just yet

[Kixunil]

I've noticed you plan to stabilize the crate which is a great goal but given that you expose rust-bitcoin API (pub extern crate bitcoin at minimum) it's not really realistic at this point. Rust-bicoin is not stable yet and we know of some things we will very likely break. We're working on this but it'll still take some time. If you need to stabilize sooner, please consider helping us. One thing that will make this easier is splitting up the crate and stabilizing smaller parts that we're confident about. It'd be helpful to know which parts do you expose in public API. (I can't investigate right now.)

[notmandatory]

My goal with the BDK 1.0 API is only to stabilize our public 'bdk' crate APIs, meaning any users who build a wallet with those APIs can go ahead and build their apps without worrying about frequent breaking changes. That means we won't change the rust-bitcoin types we export until we do our next "major" release.

A priority for our 2.0 milestone is to bump versions of rust-bitcoin, rust-miniscript, rust-bitcoincore-rpc. I expect we'll do a major bdk version release at least yearly to upgrade all our major dependencies. The one exception to this would be if any critical security bugs are found in a dependency, but then I'd hope those would be back ported to a non-API breaking patch release for the version we're using. If that's not possible we'll look for the least disruptive way to roll it out to our users.

https://github.com/bitcoindevkit/bdk/milestones?direction=asc&sort=due_date&state=open

[Kixunil]

In my view it doesn't look good if a crate updates major version once a year or more often, so I'd recommend trying to avoid it if possible. That's of course my personal opinion and it may not be a big deal in practice.

I wonder if you have any deadline for stabiliziation - would you be able to wait for stabilization of important types in rust-bitcoin? See this proposal: rust-bitcoin/rust-bitcoin#2160 (comment)
Or maybe at least until known, planned breakages are implemented? If you have any other ideas how to improve coordination let us know!

[notmandatory]

I don't want to do a bdk major version update any more than once a year, and ideally less often as long as we're able to add new features and dependency updates in a non-breaking way. But we already expect breaking bdk changes around our transaction builder and coin selection APIs, so updating rust-bitcoin dependencies isn't the only reason we're planning a 2.0 milestone.

As for a deadline, we already have folks building apps with alpha versions of bdk who are either in production or will be soon, so our deadline was probably six months ago. That said I don't want to add any more work on your team to try and accommodate our 1.0 release schedule. If we could have a stabilized rust-bitcoin API next year for our 2.0 release I think that would be fantastic.

Would you be available to join our next team call? @nondiremanuel can put this as a topic on the agenda. https://discord.com/events/753336465005608961/1171724191733645322

[Kixunil]

I would love to join such call but I'm unable to access that link - logging in through desktop is failing and it doesn't open the server in the app.

[notmandatory]

Maybe you need to join the bdk discord server first: https://discord.gg/dstn4dQ
Usually we have the calls on Tues at 12:00 UTC, but I will confirm with @nondiremanuel, we may have had to change it for next week.

[Kixunil]

Yeah, that helped. It says Monday. My schedule is tight but I think I could make it.

[tcharding]

The one exception to this would be if any critical security bugs are found in a dependency, but then I'd hope those would be back ported to a non-API breaking patch release for the version we're using.

However this plays out, I'll go on record saying that rust-bitcoin will guarantee backport of security patches to the version that latest post-1.0 bdk release depends on.

cc @apoelstra because he publishes the releases.

[apoelstra]

Yep, I'll go on record with the same promise.

[Kixunil]

That may be too generous? If BDK doesn't upgrade for 20 years you still have to provide patches. :) But sure, for reasonable time frames that sounds good.

[notmandatory]

This issue was discussed at recent rust bitcoin summit in Nashville and BDK 1.0 will stabilize on rust-bitcoin 0.32.0, rust-miniscript 12.0.0. We will do new major BDK releases approximately yearly and so will be able to upgrade to newer stable rust-bitcoin, rust-bitcoin versions in a reasonable time frame.

[Kixunil]

Wouldn't it make more sense to just wait for primitives 1.0? It shouldn't take too long. Though maybe BDK 2.0 can be entirely stable.

[notmandatory]

Our biggest feature request for BDK is a stable API which our users needed months ago. So we will do our 1.0 now with rust-bitcoin 0.32. But don't worry we won't wait too long to do a 2.0 release with the latest stable rust-bitcoin crates.

[apoelstra]

It shouldn't take too long.

"Not too long" I expect will be pretty close to their 2.0 timeline :) (which is ~1 year after 1.0).

(Not really; primitives should be much faster; but realistically BDK needs all of primitives, addresses and hashes before they'll see the real benefits of this shift, as well as a new miniscript which also uses these crates.)

[Kixunil]

Not really; primitives should be much faster; but realistically BDK needs all of primitives, addresses and hashes before they'll see the real benefits of this shift, as well as a new miniscript which also uses these crates.

Right, those are quite big ones, especially miniscript I guess.