I would like to recommend that language and language_version be added to the podspec and Podfile syntax.
With the changes that occur in Swift through the evolution process, it would be convenient to have a way to note which language version a pod version supports.
The current way of managing different language versions requires the use of pod versions like 2.0.0-beta-1 or 2.0.0-swift-3. When a new release version of the pod with a language update is created, developers are required to bump the major version number of their pod, even if no major changes to their pod were made. Minor language conversions should not necessarily require a major version bump in my opinion.
I would expect this functionality to work very similarly to the way platform and deployment_target currently work. If the language_version in the podspec is higher than the language_version listed in the Podfile, then CocoaPods should look for an earlier version of the pod that fulfills the dependency as that version would be incompatible. Obviously if the Podfile and podspec have different values for language, this wouldn't matter, as a bridging header would be used.
Does this seem like a useful feature to others? Any thoughts on the viability of implementing this?
We discussed this in https://github.com/CocoaPods/CocoaPods/pull/5650 and the general consensus seemed to be keeping this out of the podspec
@segiddins Got it, thanks. I see that we are using the swift-version file. That's fine.
However I'm still getting build errors while using that for having an unspecified value for Use Legacy Swift Version. Every time I run a pod install I have to go manually set that to No for all of my pods. Can it be made so that if a pod uses a swift-version of 3.0 then that config is set automatically on pod install?
Our current thinking is adding a minimum swift version DSL attribute ( to replace/augment the current .swift-version support )
Rough gist:
Mainly, this feels like CocoaPods can break a user's flow the least.
Alright. It would just be good to have something that sets the config properly so that projects build immediately after a pod install. A minimum swift version DSL attribute should work.
There are a handful of reasons why we don't plan to implement this in the near future. We're going to detail the issues around this in the blog post for the upcoming 1.1.0 release. The draft of the post is here: CocoaPods/blog.cocoapods.org#135. Going to close this, since I think this is mostly figured out for the 1.1.0 release. Once Swift 4 comes out, we might want to re-open this.
this should be revisited for swift 4. as now the pod should know what version it is on
this should be reopen for Xcode 9 and swift 4.
In Xcode 9 each target can specify a swift version 3.2 or 4.
A podspec should provide the information about the version of swift it is intended to be build with. (3.2 or 4)
Since podspec define this right now we need a way to give cocoa pods a way to deal with this today, like by providing a feature like this:
s.dependency 'Alamofire', '4.5.1', 'swift-3.2'
That way the pod project could configure each target to the proper swift version.
This 'swift-3.2' should be used as a default value to be used if the podspec of the dependency doesn't define a swift version.
Does anybody have a workaround because I cannot release my swift 4.0 pod now. When I do pod trunk --allow-warnings push Faro.podspec it tries to build with the wrong swift version.
I'm going to lock this thread as all modern discussion is in https://github.com/CocoaPods/CocoaPods/issues/7134
@doozMen please don't post off-topic on threads, that's a perfect stack overflow question as it's about your usage of CocoaPods. ( Sidenote: it's about your Command Line Tool location in Xcode's prefs )
Most helpful comment
this should be reopen for Xcode 9 and swift 4.
In Xcode 9 each target can specify a swift version 3.2 or 4.
A podspec should provide the information about the version of swift it is intended to be build with. (3.2 or 4)
Since podspec define this right now we need a way to give cocoa pods a way to deal with this today, like by providing a feature like this:
s.dependency 'Alamofire', '4.5.1', 'swift-3.2'That way the pod project could configure each target to the proper swift version.
This 'swift-3.2' should be used as a default value to be used if the podspec of the dependency doesn't define a swift version.