<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 27, 2017, at 9:19 AM, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span></div></blockquote></div></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I haven't spend much time thinking about the implications, but wouldn't it be feasible to freeze old frameworks completely when a new Swift version is added?<div class="">After all, bundled code isn't updated at all, so I see no downside here — actually, it only adds flexibility that could be utilised when critical bugs are discovered.</div></div></div></blockquote><br class=""></div><div>You can't simply freeze an old version of a framework. Many app frameworks have interfaces with other OS components. Freezing the app side of the interface also constrains the other side, effectively introducing another piece of ABI that must be kept stable.</div><div><br class=""></div><div>For example, CoreGraphics needs to talk to the window server. If you try to freeze some version of CoreGraphics then you require the window server to implement that particular interface forever. Now the window server's private interface has become an ABI that must preserve binary compatibility. The same is true for the spellcheck server, the pasteboard server, the address book database server, and a great many others.</div><div><br class=""></div><div><br class=""></div><div>--&nbsp;</div><div>Greg Parker &nbsp; &nbsp; <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a>&nbsp; &nbsp; &nbsp;Runtime Wrangler</div><div><br class=""></div><div><br class=""></div></body></html>