Repository navigation
rustls Sync / Integration Lock-Step #33
Description
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 ?
Activity
pinkforest commentedon Mar 18, 2024
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 commentedon Mar 18, 2024
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
rustlsversion 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 ofrustls.pinkforest commentedon Mar 18, 2024
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.0over thatby 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 commentedon Mar 18, 2024
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 workstarcieri commentedon Mar 18, 2024
We could do something like that, although I'm used to
+X.Y.Zspecifically in the context of-srcreleases 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 commentedon Mar 18, 2024
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 commentedon Mar 19, 2024
I think we have consensus here so can close as completed - re-open if need to be visited / someone has better idea/s