chore: update MSRV to 1.63

[robjtede]

Motivation

Maintaining such an old MSRV is fighting a losing battle; trust me, I've tried.

(Somewhat hillariously,) Cargo's resolver will prefer to downgrade tera versions to allow higher compatible chrono-tz & thread_local versions. So, this pinning scheme is somewhat fruitless anyway; blocking many users from being able to access newer Tera features and fixes. (This might, in part, explain why download numbers on crates.io still seem to favor of v1.17.1.)

 › cargo update
    Updating crates.io index
    Updating chrono-tz v0.6.1 -> v0.6.3
    Updating chrono-tz-build v0.0.2 -> v0.0.3
      Adding humansize v1.1.1
      Adding phf_codegen v0.11.2
      Adding phf_generator v0.11.2
 Downgrading tera v1.19.0 -> v1.17.1
    Updating thread_local v1.1.4 -> v1.1.7

Notes

The concensus among most crates (evidently) and authors is that an MSRV bump is not classed as a breaking change.

I've used 1.63 as the minimal update necessary for builds to succeed without pinning transitive deps. Though, for future-proofing, I'd actually suggest something quite a bit higher like 1.65, released Nov 2022, so a good support timespan still.

closes #833

[Keats]

I think I'm not going to do another release until v2

[robjtede]

Apologies for the noise @Keats, but I'd encourage you to create such breaking releases soon rather than later, as I wish I'd done with Actix Web v4.

[Keats]

I will do a small release for that since i don't know when i will be done with tera v2. Can you fix the CI?

[shepmaster]

this pinning scheme is somewhat fruitless anyway

As I stumbled here from something tangentially related, I'll add my two cents. I do not think that pinning your dependencies in the crate is the correct way to maintain a MSRV. In SNAFU, I support all the way back to Rust 1.34. I use two main techniques:

1. Feature flags for opting into things that need newer Rust versions. I enable some of these by default (the Rust versions that are at least 1 year old at the time of release) and others can be opted into by the end user depending on their knowledge of their project.
2. A set of compatibility tests that ensure that older versions of Rust can still compile the crate. Notably, only the tests pin older versions of transitive dependencies, not the crate itself.

Most people use newer versions of Rust and are in the happy default path. The minority that need older versions can still use the crate with a little extra work.

The concensus among most crates (evidently) and authors is that an MSRV bump is not classed as a breaking change.

This may be, but I think what's more important is for each crate to document their decision on the matter. I am one of the (apparent) minority that does think that a MSRV bump mandates a semver-incompatible release.