Fails to build on rustc 1.29

[TheBlueMatt]

Looks like its an easy fix to replace trim_end_matches with trim_left_matches.

[alexcrichton]

I only personally support the current stable release and prior, but PRs are welcome to preserve compatibility with older versions

[TheBlueMatt]

Seems like this was broken in an unrelated PR (#363) explicitly. Even if older versions aren't explicitly supported, is it possible to avoid needless breaks like that? Nontrivial in-production downstream users care about this functionality.

[alexcrichton]

@TheBlueMatt it was not unrelated because CI was broken. It wasn't needless because the PR couldn't land without breaking CI. A fix, required to land the PR, was implemented in accordance with the version compatibility policy and it was published.

Typically users which are held back on older compilers have lock files which prevent dependencies from being upgraded. Does your use case not use lock files? Or would it be possible to use lock files?

[TheBlueMatt]

Indeed, I'd missed that deny(warnings) was making CI fail. Sadly, lock files aren't a solution here. In the various https://github.com/rust-bitcoin/ projects we (a) wish to support people who prefer to use things like stable versions of Linux distros, eg Debian Stable (say what you will about that decision, lots and lots of people chose, sometimes for very good reason, sometimes less so to use that, and don't want to go downloading binaries from other vendors and running them), and (b) have in-production folks (including companies which employ rust-bitcoin project developers) who want to update rust-bitcoin libraries, potentially which wish to use newer cc features, without having to certify an entire new rustc version.

At the end of the day, nearly every large, security-sensitive, or life-critical software companies wish to vendor everything, and while lock files (or, really, cargo vendor) prevent random things from getting upgraded out from under them, being able to upgrade one piece without having to upgrade everything is a pretty critical feature. Obviously given that rust is still kinda too young for stable projects like that I totally don't expect the entire ecosystem to want to maintain backwards compatibility and not be able to use new, important features, but for crates like this one that are (a) super important across the rust ecosystem and (b) for changes that take about as much time and effort to just support the old version as switch to a new version, I think it would be immensely valuable for the maturation of Rust as a whole if the option to just support older compilers was taken.

[apoelstra]

Also, cargo ignores lockfiles in libraries. We could use them to make our own CI work, and then we'd be testing with different versions of dependencies than our users, which would put us in an even worse position when breaking changes happen in minor versions.

[alexcrichton]

@TheBlueMatt I don't disagree, I was pointing out that your analysis was incorrect in a few places. Your explanation is exactly why I'm fine merging PRs and publishing them which support older compilers without bending over backwards too much.

[alexcrichton]

Fixed in #365