Rust release support

[jkczyz]

There's some useful features in Rust's stable release. However, we have Travis configured for some older releases.

https://github.com/rust-bitcoin/rust-lightning/blob/f70058ea4c451955e72b15d24b67d941d7f3e467/.travis.yml#L2-L6

#15 added 1.22 when adding fuzzing. #220 added 1.29.2 because stable (1.30 at the time) broke fuzzing. #353 replaced 1.29.2 with 1.34.2 to get integer atomics for fuzzing.

Is there a reason to support Rust 1.22 still? What criteria should we use to determine supported releases?

[jeandudey]

Is there a reason to support Rust 1.22 still? What criteria should we use to determine supported releases?

Debian oldstable rustc package

[TheBlueMatt]

See-also rust-bitcoin/rust-bitcoin#338. Probably best to continue the discussion there unless we have an urgent need to support a different version than rust-bitcoin itself.

[jkczyz]

See-also rust-bitcoin/rust-bitcoin#338. Probably best to continue the discussion there unless we have an urgent need to support a different version than rust-bitcoin itself.

I don't see an urgent need to support a different version, but there are features such as native endianness support that would be nice to have rather than rolling it ourselves. Also, my limited understanding of the Rust RFC and release process is that it takes awhile for new features to be released to stable. So we'd have to wait even longer for upcoming features.

Debian oldstable rustc package

Maybe a better question then is: what criteria should we use to determine supported OS distributions? IIUC, developers want to use rust-bitcoin in Bitcoin Core, so the supported distros are limited to those supported by Core. But given rust-bitcoin is a dependency of rust-lightning and not vice versa, why should rust-lightning use similar criteria?

[jeandudey]

there are features such as native endianness support that would be nice to have rather than rolling it ourselves.

And will be used once the MSRV is updated to a more recent version.

But given rust-bitcoin is a dependency of rust-lightning and not vice versa, why should rust-lightning use similar criteria?

The ability to spin up a rust-lightning implementation in older systems that don't support recent Rust versions.

---

The main goal is to be able to build everywhere (Rust suffers a lot since crates upgrade their MSRV constantly) without using rustup, and building deterministically on a system that you trust.

[jkczyz]

Wanted to circle back to this as we've been running into problems where we have to write code in a more verbose way to placate 1.22.

Debian oldstable is now at 1.34: rust-bitcoin/rust-bitcoin#338 (comment)

[jeandudey]

Seems reasonable since Debian oldoldstable got support for 1.34 too.

[TheBlueMatt]

Hmm, I've never had any issues just making things a tinge more verbose to get 1.22 to build, but I'm also open to bumping it. Unless we have a strong reason not to, I'd prefer to have the same MSRV as rust-bitcoin, but maybe we can bump it to 1.29 given mrustc seems to mostly be focusing there. rust-bitcoin/rust-bitcoin#338

[jkczyz]

Here's one example:

b4921e9

There are similar examples in that PR that go away in 1.31, AFAICT. My preference would be to go to 1.34.

[TheBlueMatt]

Past 1.29 would be quite annoying to bootstrap a compiler, AFAIU, as mrustc only supports 1.29.

[jkczyz]

I was not familiar with the requirements around using mrustc for bootstrapping. I found rust-bitcoin/rust-bitcoin#206, but from my reading I don't see how it is a problem. See: rust-bitcoin/rust-bitcoin#206 (comment)

[TheBlueMatt]

Right, the only way to build a later version of rust with mrustc is to compile each previous version. Thus, relying on anything much later than 1.29 makes it relatively impractical to do.

[jkczyz]

I'm not sure I understand why this is impractical. Isn't this a one-off event whenever we want to bump releases? Maybe I'm missing something obvious or don't understand what exact use case is being targeted in practice.