rustls Sync / Integration Lock-Step

[pinkforest]

Q: How to keep development in lock-step with rustls releases

This should handle all API changes for minor / major in Rustls whilst supporting previous minor branch

Figure out if it's feasible to:

• Keep main for the current latest version and tag older minor/major in branch
• Bump major version here every time rustls bumps - e.g. rustls-rustcrypto 0.23 bump major in the provider ?

[pinkforest]

Problem chiefly here is that there is both rustls and the provider here as discrete APIs where our API may break independently from rustls.
MSRV may bump beyond over rustls would typically require at least bumping the minor version leading to inconsistency where patch version may break MSRV commitment.
ref: #51 (comment)

[tarcieri]

It seems like the main place we'd need to potentially making breaking changes is between rustls upgrades, which are at least currently frequent.

Having a version number different from the rustls version number would lead to downstream confusion from anyone trying to use/upgrade the provider as to what versions of the provider are compatible with a given version of rustls.

[pinkforest]

yeah - openssl-src has a pattern of C-library-version+Rust-version which seems to work - so first version really could be 0.23.0+0.1.0 - and this is perfecly legal in SemVer too as buildinfo :)

and if there is need to bump whilst targeting rustls 0.23 could release 0.23.1+0.2.0 over that

by that definining dependency as:
rustcrypto-rustls = { version = "0.23" }

Will get any 0.23 version as per normal despite the build meta where we at least signal MSRV / our breaking changes if any.

[pinkforest]

Eeps no, it was some formulated_version+c-library .. needs some type of formula - openssl-src also integrated several release streams same time e.g. 1.1.1 and 3.0.0 branches so they really had to come up with a system that works

[tarcieri]

We could do something like that, although I'm used to +X.Y.Z specifically in the context of -src releases as "this contains a repackaging of openssl X.Y.Z", as opposed to "this is compatible with but does not contain (in this case) rustls X.Y".

Users could probably infer it's the rustls version, though. That said, it's quite visually noisy.

[pinkforest]

I agree on the visual noise - so think it's just additional complexity. Perhaps we can signal MSRV given that is probably the only thing changing ? But yes again visual noise

So perhaps we can both just keep it at 0.23.X which matches any 0.23.Y from rustls and hope that people will read documentation and know / be informed that we will not guarantee MSRV staying the same in any way across same minor version what people would usually expect.

[pinkforest]

I think we have consensus here so can close as completed - re-open if need to be visited / someone has better idea/s