[Pitch] Version-pinned patching of public declarations


(Curt Clifton) #1

I'm late to this thread and replying via a mail-to link from the archives, for both I apologize.

I wanted to express my support for this proposal. I'm pleased that it addresses the specific concerns that I and others raised in the discussion of final/sealed-by-default regarding the need for some sort of escape hatch to work around framework bugs. Keying patches to specific framework or OS revisions seems like a reasonable approach. I brought the idea up at Seattle Xcoders this week and there was general agreement that folks were happy to update their apps for updated framework versions, whether to remove no longer necessary patches or to specify that some patches were still needed.

There are lots of interesting corner cases, of course, to deal with customers who update their OS but don't update an app and vice versa, but lifting patches to the language level seems like a promising way to improve robustness while decreasing the burden on framework authors of dragging "do not break" apps along.

Thanks again for the proposal.

Cheers,

Curt

Curt Clifton, PhD
Software Developer
The Omni Group


(Ari Weinstein) #2

Hi all,

I just wanted to throw some more support behind this. Having such a
patching mechanism built-in to the language and allowing developers to work
around the inevitable bugs in frameworks (system or otherwise) would be a
huge boon to the developer community and ultimately, users.

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.

Ari

Ari Weinstein
Co-founder of Workflow

···

On Sun, Jan 17, 2016 at 9:40 PM, Curt Clifton via swift-evolution < swift-evolution@swift.org> wrote:

I'm late to this thread and replying via a mail-to link from the archives,
for both I apologize.

I wanted to express my support for this proposal. I'm pleased that it
addresses the specific concerns that I and others raised in the discussion
of final/sealed-by-default regarding the need for some sort of escape hatch
to work around framework bugs. Keying patches to specific framework or OS
revisions seems like a reasonable approach. I brought the idea up at
Seattle Xcoders this week and there was general agreement that folks were
happy to update their apps for updated framework versions, whether to
remove no longer necessary patches or to specify that some patches were
still needed.

There are lots of interesting corner cases, of course, to deal with
customers who update their OS but don't update an app and vice versa, but
lifting patches to the language level seems like a promising way to improve
robustness while decreasing the burden on framework authors of dragging "do
not break" apps along.

Thanks again for the proposal.

Cheers,

Curt

Curt Clifton, PhD
Software Developer
The Omni Group

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Brent Royal-Gordon) #3

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