Allow cross-version linkage

[SergioBenitez]

Bringing this over from #535.

Being able to link two versions of ring into one binary is incredibly important, and it will become even more important as ring gains adoption. In fact, being able to link two versions at once was the primary reason why I've used ring as opposed to openssl in my projects. I want to illustrate why in hopes that ability to link two versions of ring at once is prioritized.

The current state of affairs forces a lock-step upgrade of dependencies. Consider what Rocket had to do to upgrade from cookie 0.8 to cookie 0.9, which updated ring to 0.11. First, the cookie dependency was updated to 0.9. This caused a breakage since Rocket also depends on rustls and hyper-rustls which depended on ring 0.9. I maintain a fork of hyper-rustls, but I couldn't update it to ring 0.11 because it depends on rustls. So, I opened up an issue on rustls. rustls itself depended on webpki-roots, which depends on ring. So, webpki-roots had to be updated. Thankfully, it had no downstream uses of ring, so it updated just fine. Once webpki-roots was updated, rustls was updated. Once rustls was updated, hyper-rustls was updated. Finally, once hyper-rustls was updated, I could update the three ring-related dependencies in Rocket. To upgrade one dependency in Rocket, I had to force updates to 3 other crates. All because of ring.

Thankfully, @ctz owns rustls and webpki-roots, and I maintain cookie, so this was able to happen rather quickly. What if this hadn't been the case? How long would it have taken for the upgrade to happen? Your goal is for users to always be on the latest version of ring, but I think you'll see just the opposite as users are forced to the least common denominator.

Additionally, ring is most likely to be used as an internal library. It's unlikely that two libraries will interface through ring's types. This is where Cargo/Rust's ability to have two versions of the same library in one project shines! It's a shame that we've lost this benefit. And, what's worse, ring now directly controls when a library has to release a breaking change. This is a massive inversion of control; I really don't want a dependency controlling my version numbers. Again, I think you'll see many projects refusing to update ring as a result, leading to libraries on old versions of ring.

cc @alexcrichton

[andrewtj]

Is this under consideration?

[lbolla]

Is this ticket being worked on?

[andrewtj]

@briansmith are you considering this? Would you entertain PRs that prefix the appropriate symbols?

[briansmith]

@briansmith are you considering this? Would you entertain PRs that prefix the appropriate symbols?

No, I am not working on it and I'm not interested in such a PR, at least at this time.

[SergioBenitez]

@briansmith Can you say more? Your decision seems arbitrary and baseless. I can only see an upside towards implementing this, but perhaps you're considering something I'm not.

[briansmith]

I only support the latest released version of ring. This feature proposal is only for supporting versions of ring that aren't the latest released version, so it's out of scope., like I said before. I'm not interested in changing the policy or debating it further.

[briansmith]

A while back, @andrewtj wrote:

@briansmith are you considering this? Would you entertain PRs that prefix the appropriate symbols?

I'm not working on it but I sketched the requirements for a solution for it in #535, which I reopened and which is unlocked. Let's discuss this in #535.