Summary: | Remove some support for < iOS 13 | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Keith Rollin <krollin> | ||||
Component: | WebKit Misc. | Assignee: | Keith Rollin <krollin> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | achristensen, commit-queue, joepeck, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=201851 | ||||||
Attachments: |
|
Description
Keith Rollin
2019-09-19 21:27:13 PDT
Created attachment 379206 [details]
Patch
Comment on attachment 379206 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=379206&action=review > Source/WebCore/PAL/pal/spi/cf/CFNetworkSPI.h:222 > +#if PLATFORM(MAC) || PLATFORM(IOS_FAMILY) These should just be PLATFORM(COCOA) I noted in my comment that I was going to perform that cleanup later. I'd like to keep each patch focussed on one type of change. So can I land it now anyway? I don't see any reason to do this in two changes. It's not hard to follow, and it would merge cleanly if we merged this to a branch. My reason is that this current patch is part of a much larger body of work, and I don't want to distract myself by going down other paths at the point. I have a process to manage all these details. Getting to the change you want is part of that, but it comes later. Comment on attachment 379206 [details]
Patch
I'm assuming that means you have a long train of git commits that would need rebasing if we changed this. Whatever. You should have a work flow that is more open to review changing things.
Comment on attachment 379206 [details] Patch Clearing flags on attachment: 379206 Committed r250171: <https://trac.webkit.org/changeset/250171> All reviewed patches have been landed. Closing bug. |