Xcode 8.3 and Swift 3.x support

[Liquidsoul]

This pull request is mostly a merge of the swift-3.0 branch to implement #233 :

• it makes master use Swift 3.0 as default.
• it fixes some string warnings in some logs from Xcode 8.3.

Once this is merged we will create a swift-2.3 branch to allow users to use the legacy Swift version if they need it.

❓~One thing I am wondering is if the Travis CI configuration should not be updated in this PR to test both Xcode 8.3 and Xcode 8.2? Maybe at least change the osx_image to xcode8.3 instead of xcode8 which from travis' documentation targets some Xcode 8 GM~ 🙄 The build matrix has been updated to use Xcode 8.3.

A language badge has been added to the README file.

[AliSoftware]

I think by now it would be better to have the following branch setup:

• Make master always use the latest Swift version, even if it's early in adoption (so in our case today, Swift 3.1)
• Make dedicated branches for older versions, so swift-2.3 and swift-3.0

Because if today we make master use 3.0 and make a swift-2.3 and swift-3.1 branch we'll later again fall back in the similar issue we have today once 3.1 will be widely adopted.

Thoughts?

[AliSoftware]

❓One thing I am wondering is if the Travis CI configuration should not be updated in this PR to test both Xcode 8.3 and Xcode 8.2?

Yeah probably :+1:

_(Just to be clear, we won't need a build matrix to always build master on all Xcode's, just each branch — master, swift-2.3 and swift-3.0 will each have their travis.yml configured with the matching osx_image for the branch)_

[Liquidsoul]

Is there really a difference between Swift 3.1 and Swift 3.0? Because it does not seem to be the case or maybe I am missing something 🤔

[AliSoftware]

I don't think there is any code change needed at all. The only requested changes is for Carthage users, again… who will require us to do a branch on which the only difference compared to 3.0 would be the value of SWIFT_VERSION

[AliSoftware]

Side note: we need to migrate OHHTTPStubs to Circle-CI some day… travis is still taking forever :'(

[AliSoftware]

@Liquidsoul Now that this is merged:

• master is in Swift 3.1
• I've moved the swift-3.0 branch to be equal to master, so that people referencing that branch (especially people using Carthage) can still use it. We'll remove it as soon as we publish a new release/tag
• I've created a swift-2.3 branch (that is equal to where master was before the merge of that PR)

Next steps is to:

• Add a commit to that new swift-2.3 branch to add the shields.io badge in the README
• Create a new release x.y.z (version to determine)
• Tag the branch master with x.y.z but also the branch swift-2.3 with x.y.z-swift2.3
• Remove the swift-3.0 branch
• Profit!

[Liquidsoul]

@AliSoftware I've just pushed the badge in branch swift2.3.

[AliSoftware]

👌

[krunk4ever]

I noticed that the releases are versioned as:

• 5.2.2
• 5.2.2-swift3
• 5.2.3
• 5.2.3-swift3

Moving forward, will this be switched to?

• 5.2.4
• 5.2.4-swift23

[AliSoftware]

Yep exactly that's what I plan indeed. Do you think we should do otherwise? Suggestions welcome.

Also wondering if I should bump the next release to 6.0.0 because the switch from 2.3 to 3.0 is source-breaking (I think, will have to compare our APIs for the two versions to check if the call site has to be changed or not 🤔)…

[krunk4ever]

I agree you should make 5.2.3 not compatible with the next version since they are not compatible, so 👍 on 6.0.0