I just moved the lowest supported rust version to 1.31, since that's where the 2018 edition started (from 1.27), and 1.31 doesn't have this. That said, if you can make a compelling case for bumping the lowest supported version of rust, I'm not opposed to it.

There is in fact no strong case except general ecosystem hygiene; I'm going around removing byteorder here and there since it shows up in the deplist so very often.

Beware that due to TryInto the minimum version would raise to 1.34.

Put it on the shelf if so desired.

OK. This is a good change; let's leave it just as is for a couple weeks and let people weigh on supporting old rust vs fewer dependencies.

Do people use old stable rust? I suppose some people must; I don't.

I don't think a crate like base64 can justify requiring such a new version of the compiler.

I tend to disagree: Rustc is moving fast, yet it has proven to be very stable. There is simply no reason - unlike with GCC - to dwell on older compiler releases. Other dependencies by upstream will cause the minimum Rust version to be recent-lish, even if base64 falls behind. Besides, 1.34 was released four months ago; it is even in Debian buster.

Well, Debian Buster is only 2 months old, so the majority of Debian users are probably on Jessie, which has Rust 1.24.

Also, in high-assurances environments, it's common to perform an audit on a software stack and stick to it because re-auditing costs a lot of time and money. That's part of the reason why things like LTS distros exist.

Let me refer to this comment for more context: #112 (comment)

Anyway, I'm not against removing the byteorder dependency, but I'm not strongly in favor either. byteorder is one of the good examples of a crate that does a simple thing, is very stable and is compatible with very old Rust versions.

Done via #111.