Decide how cargo.lock and MSRV interrelate

On #376 (closed), I asked:

As a side-note, do we care if our Cargo.lock file requires a newer rust than our MSRV? I say "no", but we should open another ticket to discuss if so.

This is that ticket.

changed milestone to %Arti 1.0.0: Ready for production use

With MSRV now being 1.56, this might be the ideal time to make a decision. As of now, our main Cargo.lock is compatible with rust 1.56, so ./maint/downgrade_dependencies is basically useless.

As it was impossible to have a 1.53-compatible Cargo.lock without having outdated dependencies (many with RUSTSECs associated), I used to be against considering Cargo.lock to be included in Arti MSRV guarantees.
As our MSRV increased, it's now possible (and rather easy, we just have to keep it the way it is currently), so I'd personally be in favor of it being included in Arti MSRV guarantee

As of now, our main Cargo.lock is compatible with rust 1.56, so ./maint/downgrade_dependencies is basically useless.

As a side note, this isn't the case. The downgrade_dependencies script isn't there to support our minimal-Rust version: it's there to make sure that we actually build with the oldest versions listed in our Cargo.toml files. Without it, we might require a version of some dependency newer than we actually list in our Cargo.toml files.

I'll add a comment about this.

ho yes, my bad

Since we only support the versions in our Cargo.lock, I think it must be included. That is, our Cargo.lock ought to build with our MSRV.

Hm. I understand the reasons for saying that we only support the versions in our Cargo.lock, but perhaps we ought to refine this idea. After all, we keep earlier versions in our Cargo.toml files, and we allow people to build with those, so those earlier versions are in some sense supported. So we need to decide whether our MSRV is supported in the same sense the versions in our Cargo.lock file, or whether it is supported in the same sense as the versions in our Cargo.toml file.

Maybe we want to define multiple levels of supportedness…

mentioned in merge request !480 (merged)

added Doing label

assigned to @nickm

added Q2 label

We chatted about this a little today, and generally decided that our best way forward is not to try to divide things into strict "supported!" and "not supported!" categories, but instead to come up with descriptions of what exactly we do and don't guarantee. Examples we I liked included the Rust tier list and the C Tor supported platform list.

mentioned in merge request !513 (merged)

added 2h of time spent

added Needs Review label and removed Doing label

added 2h of time spent

mentioned in commit bc3c9d47

closed with merge request !513 (merged)