Why was a breaking change introduced in a minor?

[LekoArts]

Hi!

Our users reported errors in Gatsby due to a breaking change of socket.io in a minor: gatsbyjs/gatsby#28877

This is really unfortunate as we don't pin our dependencies and rely on correct semantic versioning. As we'll update to a newer version of socket.io eventually, is there the chance to have breaking changes in a minor again? If yes, is this outlined somewhere in a document? If not, why was this change made instead of e.g. warning/deprecating the version.

Thanks!

[darrachequesne]

Hi!

The change is documented here:

• https://github.com/socketio/socket.io/releases/tag/2.4.0
• https://socket.io/blog/socket-io-2-4-0/

This is indeed a breaking change which was required in order to solve a security issue that affects all previous versions (please see the release notes for all details). Honest question: is there something we could have done better? I'm open to suggestions on this.

[LekoArts]

Thanks for the quick answer!

What I meant with

If yes, is this outlined somewhere in a document?

Since you deviated from the semantic versioning, do you have a document where you outline your publishing policy? As this is not something one can expect.

Honest question: is there something we could have done better? I'm open to suggestions on this.

I think the proper way would be to deprecate the v2 version and prompt people to update to v3:
https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions#deprecating-a-single-version-of-a-package

This way we'd probably also be made aware of the security fixes in v3 but without breaking changes. While I get it's a security fix, it broke our development server as we relied on semantic versioning.

[darrachequesne]

That makes sense, thanks a lot for your response. The change was reverted in 2.4.1.

Regarding the deprecation, my only concern is that upgrading to v3 is not as smooth as we would like, since a v2 client cannot (at least currently) connect to a v3 server.

[kalik1]

Hi, in our development server, we had the same issue, even with the 2.4.1. We also rely on semantic versioning, and our solution (not so loved) was to fix version in package.json.... It will be very apreciated to not deviate from semantic versioning.

Thanks :)