-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leverage Swift 5.1 module stability #64
Comments
I haven't tested that, but given this actually works with dynamic frameworks I think we could support this feature with an option at first. My reasoning is that although ABI stability is a given now, we still don't know how things go in practical terms and especially given that some frameworks might opt for adding some new features only for newer Swift versions, we might miss out on supporting the latest technology if we make this the default behavior. Not sure if I explained it well, so here's an example: Let's a framework – let's name it X – introduces a new syntax or new API in version 2.0 only for Swift 6.0 users and has a fallback for Swift 5.1 users which is less concise but still works, and let's say that someone is still running on Swift 5.1 although Swift 6.0 is released, then this user will build that framework with Swift 5.1 and cache the results. Then, when she updates to Swift 6.0 sometime later, she will still get the Swift 5.1 API since it was built with Swift 5.1 – at least that's how I understand it (haven't tested though). This way defaulting to always using compatible cached versions might make users miss out on new features and get confused, why they are not available. Also, optimizations on Swift performance might not automatically be apparent on those cached products. Also, given that new Swift versions do not appear so often, I think we can comprise having to build dependencies twice a year or so. By the way, I don't think we should in any way optimize for using Beta versions at all. Having this all said, I'm not against adding this as an option for those, who need this. |
@Dschee Not enabling this by default totally makes sense to me, but I'm uncertain whether anyone would actually use a flag with the |
I think given Apple was quicker than expected with integrating SwiftPM into Xcode renders many features "not worth implementing", including this. We shall have to play around a little more with the given inclusion into Xcode and from that drive a new direction for Accio to go. I feel like there's still space for Accio here to provide a bridge between now and the time all frameworks properly support inclusion into Xcode via SwiftPM. They are still missing resources support, for example ... |
Closing this as not worth implementing (see discussion above) |
An idea originating from #62, if the Swift version, let it be
v
, is greater than5.1
(the Swift version where module stability is introduced), the cache should also be looked up for versions built with a versionw
,v ≥ w ≥ 5.1
. If a cached build product with versionw
is found, then it can be used, even with Swift versionv
.The text was updated successfully, but these errors were encountered: