This was originally mentioned on the swift-nio issue tracker here, but the issue tracker doesn't necessarily get a load of traffic so I wanted to bring this up on the forums.
Specifically, it seems like it would be useful to try to come to a community understanding of how semantic versioning should map to Swift. Swift is in a uniquely difficult place becuase of the way it allows users to extend arbitrary types.
For the rest of this post I'll use a hypothetical package A, that depends on packages B and C. In particular, this package can run into the following cases:
- Package A may conform a type from Package B to a protocol from Package C. If Package B later adds that conformance, this will cause a compile error. (This is very common in the Swift community in the case where Package C == the Swift standard library).
- Package A may extend a type from Package B with a method or computed property. At some later time, Package C publicly extends the same type from Package B with the same method or computed property. This will cause a compile error in package A.
These possibilities require us to revise what is commonly accepted as a "breaking" change in SemVer for the Swift community. Given that the Swift language entirely allows both 1) and 2) above, in principle it becomes almost impossible to make a SemVer-minor change to a Swift library, as it could always conflict with a hypothetical public extension in a third-party library that depends on it. This interpretation makes SemVer almost entirely useless for Swift, as there will never be a SemVer-minor: only SemVer-patch and SemVer-major.
Because we don't want SemVer to be useless, we should as a community come up with a set of guidelines as to what kinds of changes are safe for SemVer-minor. This will need to involve defining a set of best-practices regarding type extensions such that software that follows them will safely get the SemVer guarantees.
I'd like to use this thread to solicit feedback as to what those guidelines should be.