Breaking change was introduced with minor version update
okhan-okbay-cko opened this issue · comments
Hey, this is just a heads up, when I see the diff between 1.12.0 and 1.13.0, the minimum iOS version in Package.swift seems being changed from iOS 11 to iOS 13. We were consuming the framework by defining it 1.0.0 - Next Major and we support down to iOS 12. This ended up being a breaking change for our CI/CD pipeline. I think it should've been a major version update.
@okhan-okbay-cko Sorry about that! Generally we've seen semantic versioning apply to library APIs rather than tooling requirements. If you've seen precedent for Apple or other SPM packages releasing major versions when the library APIs themselves have no breaking changes, please do share! We'd be interested to see how other libraries have managed these kinds of updates.
Our main reason for bumping the requirements to iOS 13 and swift-tools-version 5.7 is because it brings us in line with Apple's own package ecosystem, which have adopted these requirements (not sure if they did major bumps when they did). And this was required for us to depend on SwiftSyntax.
We are open to take a PR that brings back a second Package.swift@swift-5.5 if you're up for it, but we probably won't be able to guarantee its maintenance over time, so if you notice anything break, we may need assistance in keeping it in working order, or we may need to retire that support.
Hi @stephencelis,
All the things you've mentioned makes sense to me. I don't have a precedent at hand. Also, this part on semver.org supports you further, I believe.
It didn't cause a big problem for us since it was just 1 broken build and then pinning the version. Hence, I wouldn't be willing to create a PR and maintain a second Package.swift file.
Thanks for the detailed answer and this awesome tool 🙂