Only for -sys I suppose?

Correct.

An was release in October 2021: https://blog.rust-lang.org/2021/10/21/Rust-1.56.0.html

I agree that edition 2021 would be a good cut off, and the version is almost 2 years old.

However, if we go by Debian stable versions, stable has 1.63, old-stable has 1.48 and the oldest still active LTS has 1.41.1

I think 1.63 is a good cut off, will get us quite a few new features including edition 2021, and overall seems like a good choice.

+1. I think 2021 will have less maintenance for MSRV related issues.

I don't think this is related. We can still bump MSRV when stable, it's just that some MSRVs affect how nice the API can be.

That being said 1.63 is something I would like a lot due to weak dependencies and being in Debian stable.

cool, thanks!

It's not required to update the Debian OS to run 1.63 hopefully.

Currently, Debian 12 "Bookworm" has 1.63, but Debian 12 was only released recently.

Debian 11 "Bullseye" has 1.48

Debian 10 "Buster has 1.41.1

Debian users tend to only install things through the package manager for security concerns (rustup is basically a bash script you download from a website (that can be compromised) which downloads pre-built binaries for rustc, cargo, etc. from other websites (that can be compromised)... so some people will never use rustup.

Asking people "hey, you need to be on the LATEST stable Debian or else you can't build anything that depends on rust-bitcoin" is a bit much... however, by the time v1.0.0 is released, Bookworm will have been out for quite a bit... so it is reasonable to set MSRV to 1.63.

This is a little off topic, but binaries downloaded from a package manager can be compromised.. To me, the safest is to compile from source since there's a chance to audit the source code that's being installed.

binaries downloaded from a package manager can be compromised

The risk of the debian package manager being compromised is much, MUCH lower than the risk of rustup's domain and the various domains it downloads binaries from being compromised.

Case and point: Metamask, MyEtherWallet, and many other "crypto" wallets have fallen victim to BGP attacks which have lost people tons of money. Their IP addresses were hijacked and HTTPS certs were newly obtained by the hacker.

Debian package manager does not have this problem, the maintainer GPG keys are pre-installed, and the ISO downloads are all signed with trusted keys that are signed in the PGP WoT.

"HTTPS with a domain owned by a trusted entity" is secure enough for a lot of things. I think it is secure enough in most cases. I personally think rustup is great.

But saying "well, nothing is 100% secure, so might as well use something that's 3% secure vs. something that's 99.999% secure" would be the same as if you said "well, /dev/urandom COULD produce garbage entropy, so using the current timestamp to seed a PRNG is fine."

Security conscious people would disagree. Their opinion is a valid one, and as library maintainers there needs to be a balance struck between maintainability and accommodating security conscious users of the library.

FTR I have lately started experimenting with using debian-vendored crates (external dependencies) and it works surpisingly well in bookworm.

We only need MSRV for that crate. So if e.g. bech32 API doesn't need any fancy feature from newer Rust we can use the current MSRV. For the crates that would greatly benefit from newer version we need to decide if we want to bump.

Agreed. For the bottom crates I'd maybe even look into reducing the MSRV if it were possible and unlikely to cause us too much trouble.

I think weak dependencies are a pretty big deal. Any crate that has anything else than std and alloc as a dependency probably needs them.

Can we start doing this as soon as we are ready to drop the first 1.0 crate (hex-conservative or rust-bech32 perhaps)?

Or we drop the 1.0 and don't depend on it in rust-bitcoin until we do the MSRV bump, but that kinda sucks.

I would not like to go to 1.63 (or 1.64 which might be better, though I don't feel strongly about it) until it meets our "2 years old, in debian stable" rule. They will be 2 years old in late 2024.

I'd be fine stablizing edge crates at a lower MSRV if we wanted to get 1.0 out early.

Alternately we could release a 0.99, which we promise will be "1.0 except for MSRV". Which maybe something we want to do anyway, as a sort of long-term RC.

"1.0 except for MSRV"

I don't understand this. Stable doesn't mean no MSRV bumps ever. Did you think it did or do you have something else in mind? Oh, I think I get it. The only API change will be the one allowed by newer MSRV and we will know exactly what it will be? I could get behind something like that.

Heh, so that's a vote for 1.65?

I'm really tempted to wait for the next Debian release and use that one..