Semantic Versioning: Should removing a dependency be a semver major?

Thanks Cory, that’s seems to be the safe route here. Not causing needless pain to the ecosystem, thankfully it’s not “too” painful to keep the compatibility…

Thanks for reaching out!

1 Like

That's IMHO the right choice. As it stands today, it's a breaking change for the ecosystem.

And it's important for the ecosystem to be able to rely on from: "2.30.0" not breaking their code (even if they made a small mistake like not declaring their NIO dependency to the package manager).
So despite the fact that this is (IMHO) clearly a tooling problem (in Swift(PM)), we do have to treat this as SemVer major today :cry:.

3 Likes

It doesn’t violate SemVer to release a major version even though there aren’t any breaking changes. However, it is a massive pain in the neck, and I really don’t want to see this become routine or even acceptable.

Remember, major versions mean every single dependent must explicitly update their version requirements after ensuring everything still works. It needlessly inconveniences everyone using the package correctly for the sake of avoiding breakages for those (unknowingly) using it incorrectly.

That's not the only other option: the only other option, which we pursued, is to re-add the dependency but not use it.

I get that, and it seems like an adequate middle ground between what is technically correct and what makes sense right now.

Speaking of which, I think every rule in SwiftNIO’s API Contract is indicative of some form of missing language feature or unsolved problem. Not all of them have a clear potential solution, but some of them do.