Release v0.5

[Thomasdezeeuw]

/cc @abonander

[Darksonn]

Btw, you might want to add semver checking to CI like we recently did for Tokio.

[Thomasdezeeuw]

Btw, you might want to add semver checking to CI like we recently did for Tokio.

You mean https://github.com/tokio-rs/tokio/blob/ca9f7ee9f4750d6bb8a073ab4df1b7e4555857ad/.github/workflows/ci.yml#L233-L248 and https://github.com/obi1kenobi/cargo-semver-checks?

[Darksonn]

Yes.

[Thomasdezeeuw]

Created #396 for it.

[Thomasdezeeuw]

Thanks for the reviews @Darksonn

[cgwalters]

FWIW, this semver bump is causing a ripple effect bytecodealliance/cap-std@963eebf#r121651362

Not saying it was wrong to do...but I just want to ensure the cost/benefit is more visible.

[Thomasdezeeuw]

FWIW, this semver bump is causing a ripple effect bytecodealliance/cap-std@963eebf#r121651362

Not saying it was wrong to do...but I just want to ensure the cost/benefit is more visible.

I'm aware of the cost. v0.5 was required mainly to resolve #218, which showed that some of the API in v0.4 is unsound (it can use an arbitrary integer as fd without unsafe). Furthermore v0.4 is still supported, so if the unsound API is not used (incorrect) crates have plenty of time to update to v0.5.

Updating a heavily used crate in a breaking way is a pain, I'm aware, but at times it's required. v0.5 was the second breaking change in roughly the same amount of years. I try to keep a detailed changelog: https://github.com/rust-lang/socket2/blob/master/CHANGELOG.md#050 with clearly indicated API breakage and upgrade path. In other words I try to make the update experience as painless as possible.

All that said, updating existing, working code for little (perceived) benefit is always an annoying experience, just know that I'm not doing it annoy people.