[swift-evolution] [Pitch] Version-pinned patching of public declarations

[Brent Royal-Gordon]

> There are some issues with the single version-based patching approach. For example, if I'm working around a bug in a system framework in iOS 9.0, and Apple suddenly releases a bug-fix update like iOS 9.0.1 that doesn't fix the issue, I don't have the opportunity to release an update, and my patch would break. Additionally, it seems potentially unreasonable for developers would have to release updates simply to uphold patches for bugs that aren't fixed (many bugs in iOS system frameworks go several releases before being fixed).
> 
> In my head, it'd make sense for the version-patching to specify a start and end version - like, "this patch should be used when using a framework with a version between 1.2 and 2.0.1." If there is no applicable end version yet, the developer could specify only a start version, and update the app with the appropriate end version when the issue has been resolved.

The problem is, if you're working around OS bugs by patching the system frameworks, you really need to be programming defensively and testing your patches carefully. In other words, you need to qualify your releases on the new version anyway. This aspect of the patching feature simply forces you to do the work you need to be doing anyway if you're doing something so dangerous.

Unbetaed snap OS releases *are* a problem, though. Perhaps we could compromise by continuing to apply the patch on OS patch releases, so a patch qualified for 9.0.0 would also apply on 9.0.1. But with minor releases, and certainly major releases, you should always have enough time to requalify your patches, so they shouldn't automatically carry over.

I really don't think, though, that we should have open-ended patching as you propose—following @Catfish_Man gives me a lot of empathy for the poor framework engineers who have to deal with our ludicrous hacks.

-- 
Brent Royal-Gordon
Architechies