[charliesome]

I have never used Ring directly, but my experience dealing with it as a transitive dependency leads me to avoid it.

Ring has a policy[0] of only supporting the latest released version with users being expected to always upgrade to latest Ring. This in itself is not so bad, but coupled with the lack of any guarantees around API stability means that it can be a very tricky dependency to work with. This problem is compounded by it only being possible to link one version of Ring in to the same program.

Even if you don't depend on Ring directly, Ring could appear as a dependency of many of your dependencies. This forces you into upgrading all of your Ring-depending dependencies in lockstep. You cannot upgrade any until all of these dependencies support the same latest version of Ring.

This is a real shame because Ring otherwise looks fantastic. The API is misuse resistant and looks quite pleasant, and the documentation is thorough. Its current versioning and stability policy however is a massive liability for any project that relies on it. I hope this changes eventually.

[0]: https://github.com/briansmith/ring#versioning--stability

[briansmith]

> This problem is compounded by it only being possible to link one version of Ring in to the same program.

I am planning to fix this in ring early in 2021 (January)...

> Even if you don't depend on Ring directly, Ring could appear as a dependency of many of your dependencies. This forces you into upgrading all of your Ring-depending dependencies in lockstep. You cannot upgrade any until all of these dependencies support the same latest version of Ring.

Then you won't need to upgrade everything in lockstep.

That said, I still do recommend everybody only use the latest version.

[charliesome]

> I am planning to fix this in ring early in 2021 (January)...

This is definitely the piece that gives the current versioning policy its sharp edge, so it's great news that the fix will arrive soon.

Thanks for your hard work on Ring!

[Diggsey]

Thanks, this would be great! Recently had to help someone at work update our dependencies and it was difficult to justify why it was so difficult. Ring was unfortunately the cause of the difficulty.

[lambda]

It does say "Every six months we have a meeting to revisit this policy. Email ... if you want to attend the next meeting."

It sounds like he's willing to listen to feedback about the policy, but would rather have focused time dedicated to discussing it rather than long drawn out inconclusive tickets.

[BelenusMordred]

> my experience dealing with it as a transitive dependency leads me to avoid it.

This is my experience as well, it's one of the best crypto libs and the devs are topnotch, yet relying on it is often painful, many libraries out there are rendered unusable.

[est31]

Yes ring is not perfect, the issue you mentioned, or things older releases being yanked just for being old don't make it easy to deal with. But it's robust in the supported cases and written by someone who has lots of experience building cryptography software. Just recently the rustls/webpki/ring stack passed a security review.

[jturpin]

I've had the same experience in trying to use a web framework that had a dependency of a dependency of a dependency that used a yanked version of Ring. No more web framework.

I'm appreciative of all the work that has gone into Ring, its certainly not something I could have done or have any expertise in, but it is a landmine to depend on.

[trevyn]

What’s the specific reason that you can’t link in two versions?

[briansmith]

There isn't yet any name mangling in the C/assembly function names that would prevent collisions between two incompatible versions. I use `links = "ring-asm"` in Cargo.toml to prevent people from accidentally including two versions of ring for that reason. I am going to switch that to use a different mechanism.