getsentry
Bump minimum OS versions
Description
As you soon can only publish to the App Store with Xcode 15, we can bump the minimum OS of the SDK to the versions supported by Xcode 15, which are iOS 12 and later, tvOS 12 and later, watchOS 4 and later, and macOS 10.13 and later.
We don't need a major bump for this, but we should clearly point this out in the Changelog and the docs.
Continuing the discussion here on this comment: https://github.com/getsentry/sentry-cocoa/pull/3845#pullrequestreview-1993989747
Xcode 15 allows you to target macOS 10.13, iOS 12, tvOS 12, and watchOS 4. We must support these versions. This is also in our SDK Philosophy and Design Principles.
I am on board with compatibility, be we have to be able to test the platforms we claim to support. We should either prioritize getting that working, or compromise on the stance. it can still be a guideline without being absolute dogma. I think if we must choose between compromising on validated releases via automated testing, or compromising on supporting the earliest possible platform version, then automated testing should win out over compatibility.
I think this philosophy is covered in the section right above it, under "Degrade Gracefully":
If this cannot be achieved we need to make sure that we inform the user ahead of time by alerting about such situations at installation time. If for instance an SDK requires a minimum version to even build, we need to ensure that the user is informed and that we do not cause confusing errors later.
IMO This is why this should be a breaking change with a bump to 9.0.0 (which would satisfy "inform the user ahead of time"), and then in the highly unlikely event we hear from a customer that they need either a new feature or a patch on e.g. iOS <13, we could backport it in a release to 8.x.y. That, to me, is how you really hit the sweet spot between Compatibility and Graceful Degradation.
I love these principles but Compatibility is King doesn't mean support stuff no one uses, forever.
So I'd consider the data such as "how many orgs are sending data from iOS versions we're aiming to drop, on newer versions of the SDK" into account as opposed to using that as a blank card to never drop outdated versions
I am on board with compatibility, be we have to be able to test the platforms we claim to support.
It's essential we test our code on the most used / most recent platforms, of course, but I think it's acceptable not to test on all platforms we support, especially the ones almost nobody uses anymore. The major reason why we don't test our code on iOS 12 and such is because GH actions doesn't have good support for that. With our test suite in place, it mayn't reveal bugs on older, less-used OS versions, but that chance also exists on the most adopted OS versions.
IMO This is why this should be a breaking change with a bump to 9.0.0 (which would satisfy "inform the user ahead of time")
I also think we should wait with bumping until the next major version, and close https://github.com/getsentry/sentry-cocoa/pull/3845 for now.
So I'd consider the data such as "how many orgs are sending data from iOS versions we're aiming to drop, on newer versions of the SDK" into account as opposed to using that as a blank card to never drop outdated versions
Even if we don't receive much data for outdated iOS versions, dropping OS version support could be a dealbreaker for some customers. For example, TikTok and What's App still target iOS 12. While those two might never consider Sentry because they tend to build everything themselves, it would be bad for us if a similar customer still targeting iOS 12 doesn't want to use us because our latest SDK version no longer supports them.
What do we gain if we drop iOS 11 and 12 support and bump to iOS 13?
My stab at a pragmatic "ruleset"
- On a major release of the SDK, we bump the minimum versions to the supported versions of the oldest Xcode that can be used to submit to App Store
- When there's a discrepancy between that and what we can/do test on CI, we point that out in release notes. E.g. we support iOS 13+ because we test it on CI, and we allow on a best-effort basis 12 because it's still expected to work and we will provide fixes if necessary (that we can test & verify outside of CI)
We should be able to stick to that unless there's a specific reason not to. E.g. an older OS version would require significant effort to keep supporting, or there are significant workarounds in place for a OS version that are not warranted to keep around because of low adoption of the OS. Then we just discontinue support for this version altogether.
Yeah, I like the idea of "best-effort" vs "full" support, like some of the other platforms we looked at. I'm cool with doing things that way. Then our test targets could have a higher deployment target to be able to take advantage of newer API and dependencies, while our SDK is still available to those that need earlier platform version support.
I'm find closing my PR and waiting for the next major. Generally, we should plan to at least release a new major with min support bumps on each new Apple OS release every fall.