Possible semver violation

[bobozaur]

Hi,

This is only some constructive criticism, so please don't take it to heart.

I'm the author of sqlx-exasol which relies on async-tungstenite, that in turn relies on this crate.

After the CVE-2023-43669 fix the crate version was updated to 0.20.1 from 0.20.0. async-tungstenite imports this crate as 0.20, so the newer version was implicitly selected when compiling.

The problem, though, is that 0.20.1 adds a new Error enum variant and in sqlx-exasol I'm converting errors, so the new variant caused builds to suddenly fail. I personally don't think that async-tungstenite is doing something wrong with the version import, as patch version updates should not introduce breaking changes.

Given the changes in this crate, which are unfortunately breaking, would you think a minor version bump would've been more suitable? So version 0.21.0 instead of 0.20.1?

Doing this now might be more of a headache than anything else, so I'm only creating this issue to exchange opinions.

[daniel-abramov]

Hey, this all makes sense. We generally do follow the semantic version and I believe this time we just forgot to bump the minor version by accident (there were 2 security-related patches, one of which did not introduce a new error, while another did). So your reasoning is indeed correct and we should have raised a version given that the public interface changed.

[bobozaur]

Hi @daniel-abramov . Thanks for taking the time to read this and answer, I'm glad you think alike. I just wanted to raise this concern and mainly see whether it was valid or if I was just considering it to be a bigger deal than it actually was.

For now, I solved it in sqlx-exasol by directly importing tungstenite with a specific version (0.20.1) so that async-tungstenite isn't left with room for interpretation.

I'll take this as an opportunity to also say thank you for all the effort that went into tungstenite!