Xcode 8: Allowing for dependencies that support both Swift 2.3 and 3.0

[mxcl]

OHHTPStubs supports both Swift 2.3 and Swift 3.0 in its (once merged) master branch.

Thus it would be ideal if the choice of SWIFT_VERSION that its xcodeproj is built with is punted to a user-choice when executing carthage bootstrap.

I opened this ticket to discuss options.

Refs: AliSoftware/OHHTTPStubs#192

[AliSoftware]

Supporting both SWIFT_VERSION=2.3 and SWIFT_VERSION=3.0 would actually be ideal for:

• When user build the framework from source because there's no pre-build fmk or they use --no-use-binaries (an option in the Cartfile for example to tell the Swift version?)
• Pre-build frameworks (one could imagine allowing framework authors to attach both OHHTTPStubs-Swift2.3.framework.zip and OHHTTPStubs-Swift3.0.framework.zip to the GH release and hope Carthage downloads the right one automatically depending on the Swift version the user is using.

[reidmain]

Can we get someone from the Carthage team to comment on this?

It is a pretty big sticking point for people trying to migrate to Swift 2.3 or 3.

An acknowledgement that this is something that the team wants to fix or the setting of a convention that you should create separate releases for either 2.3 or 3 until you can drop support for 2.3 would be much appreciated.

[mdiep]

Can we get someone from the Carthage team to comment on this?

Sure. ☺️

I don't have time right now to add support for something like this. I've been spending all my OSS time updating things for Xcode 8 and working on ReactiveCocoa 5. Dual support for two Swift release is also not expected to happen again. (Apart from the built-in ability that will be added to swift.)

In the meantime, you should be able to do one of the following:

1. Use Carthage's --toolchain argument to point to either a 2.3 or a 3.0 toolchain.
2. You might be able to prefix usage of carthage like SWIFT_VERSION=3.0 carthage …. (I'm not sure on this, but I think it was mentioned in an issue.)
3. Break compatibility for Swift 3.0.

Personally, I choose to do (3). Apple upgrades very aggressively, so there's not much point in maintaining compatibility with old versions IMO. If you want fixes and new features, you should upgrade. I don't expected Xcode 8.1 will support Swift 2.3, so I'd upgrade ASAP.

[ikesyo]

I don't expected Xcode 8.1 will support Swift 2.3, so I'd upgrade ASAP.

FYI: Xcode 8.1 beta 1 is already released and that is shipped with Swift 3.0.1 and should still support Swift 2.3. The future Xcode 8.2 or Xcode 8.3 releases which will be shipped with Swift 3.1 may drop Swift 2.3 support.

[reidmain]

Use Carthage's --toolchain argument to point to either a 2.3 or a 3.0 toolchain.

I don't think this is necessary. Carthage simply attempts to build the xcodeproj or xcworkspace which should have the a SWIFT_VERSION build setting and xcodebuild will use the appropriate toolchain. Since you can't mix Swift 2.3 and 3 code then you need to manually ensure all of your dependencies are have the correct SWIFT_VERSION set.

You might be able to prefix usage of carthage like SWIFT_VERSION=3.0 carthage …. (I'm not sure on this, but I think it was mentioned in an issue.)

Isn't that just setting an environment variable? You could try to pass SWIFT_VERSION into xcodebuild as a build arg but I wasn't aware of Carthage having this ability.

Break compatibility for Swift 3.0.

This is what I expected Carthage's stance to be and just wanted to see it down in writing. I do think that developers should support Swift 3 in their main releases and create Swift 2.3 side releases as needed.

Personally I will be shocked if Apple drops Swift 2.3 support before Xcode 9. I bet that next WWDC we will see Swift 4 with no intermediary layer and Apple will recommend that everyone update to Swift 3 before Xcode 9 is released. Perhaps going as far as not allowing you to submit apps that build against Swift 2.3 for iOS 11.

[roddi]

Hm, now is there an easy answer to this dual language support problem or not?

With FURRDataSource I chose to have a master branch (Swift 2.3) and a swift3 branch for the main project and all of its dependencies. It works but it is quite a maintenance headache.

I really want to embrace change while not breaking backwards compatibility. I really want to leave the choice of the swift version to the user of the framework. And I really think that we should honour the fact that Apple went all the way to create those #if swift(>=...) macroish things by using them when appropriate.

And by the way: I expect future major swift versions to have breaking changes as well. So I'm pretty sure this discussion will start again with swift 4.

One last point: It would be nice to have a general mechanism that would override build settings in child projects. Think of having only one target that builds macOS, iOS, etc. by injecting the platform parameter from the super project.