Closed okhan-okbay-cko closed 11 months ago
@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 🙂
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 fromiOS 11
toiOS 13
. We were consuming the framework by defining it1.0.0 - Next Major
and we support down toiOS 12
. This ended up being a breaking change for our CI/CD pipeline. I think it should've been a major version update.