> On Jan 27, 2017, at 8:59 AM, Charlie Monroe via swift-evolution 
> <[email protected]> wrote:
>> On Jan 27, 2017, at 5:43 PM, Tino Heth <[email protected] <mailto:[email protected]>> 
>> wrote:
>> 
>>>> - runtime libraries for Swift 4
>>>> - all system frameworks will need to contain two variants - one compatible 
>>>> with Swift 4 and one with Swift 5. This is IMHO absolutely unmaintainable 
>>>> in the long run. For how long would you need to keep several versions of 
>>>> the framework around? What happens when Swift 6 comes along with another 
>>>> breaking changes? Would each system framework have 3 versions embedded?
>>> 
>>> That's right. If the OS frameworks use Swift then either (1) you have to 
>>> clone the framework stack for each Swift version, or (2) you have only one 
>>> copy of the frameworks but frameworks and apps can't share their Swift 
>>> objects or publish Swift API.
>>> 
>>> The framework structure that Apple inherited from NeXT supports framework 
>>> versioning, but *no frameworks use it*. It doesn't scale. 
>> 
>> 
>> sure, it's preferable to have a single version that works with all apps — 
>> but if it's technically possible to have one clone installed with the OS, 
>> isn't that better than one version for each app?
>> Managing several versions shouldn't be that hard (have a look at 
>> https://nixos.org/nix/ <https://nixos.org/nix/>).
> 
> It would mean for Apple (and others who'd distribute compiled frameworks) to 
> maintain several code bases of the same framework given that they would need 
> to maintain backward compatibility and hence wouldn't be able to use new 
> language features, etc. It's IMHO not that much about the technical 
> constraint of having multiple binaries within the framework bundle as much as 
> maintaining the code in a way that would compile under all Swift versions 
> you'd like to support.

Rather than Apple have to commit in perpetuity to ship all relevant versions of 
the frameworks, one could imagine more of an app-thinning/install-time 
optimization: “thinned” versions of apps would be built and signed without the 
shared system frameworks, but with dependency information recorded. At 
install-time, the app would be installed, and the working set of required 
shared frameworks on the device would be updated with any needed dependent 
frameworks. Thus the only the set of frameworks required by installed apps 
would be present on device.

This would require more app store, install-time, and perhaps dynamic linking, 
infrastructure, but would seem to solve the problem in a way that wouldn’t 
require ongoing development resources be applied to old versions.

James

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to