Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC - Multiple Swift Version Support #8191
Multiple Swift Version Support in CocoaPods
In CocoaPods 1.4.x, the
While the initial DSL served fairly well, pod authors are still willing to support multiple versions of Swift and their infrastructure often ensures their pod works with each version supported. However, today pod authors have no way of transcribing this information within their
CocoaPods has also historically supported specifying only a single Swift version during its
This proposal aims to extend the initial DSL and allow pod authors to specify a set of Swift versions supported within their
Podspec DSL Changes
The current DSL in CocoaPods is declared as a root attribute, in singular form and accepts a single
# @!method swift_version=(version) # # The version of Swift that the specification supports. # # @example # # spec.swift_version = '3.2' # # @param [String] swift_version # root_attribute :swift_version, :multi_platform => false
The DSL will be expanded to allow multiple Swift versions, in plural form and can accept both a
# @!method swift_versions=(version) # # The versions of Swift that the specification supports. A version of '4' will be treated as # '4.0' by CocoaPods and not '4.1' or '4.2'. # # **Note** The Swift compiler mostly accepts major versions and sometimes will honor minor versions. # While CocoaPods allows specifying a minor or patch version it might not be honored fully by the Swift compiler. # # @example # # spec.swift_versions = ['3.2'] # # @example # # spec.swift_versions = ['3.2', '4.0', '4.2'] # # @example # # spec.swift_version = '3.2' # # @example # # spec.swift_version = '3.2', '4.0' # # @param [String, Array<String>] swift_versions # root_attribute :swift_versions, :container => Array, :singularize => true
Each version of Swift specified in the
Even across minor Swift version updates there could be breaking compilation changes and therefore it is preferable for pod authors to explicitly specify which Swift versions (including minor ones) their pod has been tested with instead of providing unbounded requirements.
CocoaPods has historically and intentionally tried to stay away from keeping track of new Xcode releases or Swift version updates as much as possible since it is difficult to predict Apple's roadmap.
Choosing a Swift Version
Since the introduction of the
Note: While the pod author was initially allowed to publish their
Let's take the following example
Pod::Spec.new do |s| s.name = 'CannonPodder' s.version = '1.0.0' # ...other required attributes here... s.swift_versions = ['3.0', '4.0'] end
CocoaPods would still follow more or less the same strategy as described above except with this change the latest (maximum) Swift version (in this case '4.0') would be the one chosen to use for the
Handling Build Tooling Incompatibilities
Consumers of pods should be given options to filter and select a Swift version they would like to use for their projects based on the versions supported by each pod. Given that the majority of pod authors today have not migrated their
This was referenced
Oct 15, 2018
I see no reason for the Podspec attribute name to change. I should be able to take a file that says
s.swift_version = '3.2'
and update that to
s.swift_version = '3.2', '4.0'
without having to change the property name. This can still serialize to JSON as described, with a singular value serializing as
@kballard I have verified that...
s.swift_version = '3.2', '4.0'
...already works with this change.
There is a test added for it, see https://github.com/CocoaPods/Core/pull/467/files#diff-b23f0208f2c5d1e7892c8052a4ca6f15R28
It automatically creates the singular method of the DSL yes.
It will always serialize to JSON with the declared attribute key (in this case '"swift_versions"').
But for when we read the values (either declared using
Each version will be parsed for validity so if an author specifies garbage it will crash.
CocoaPods has historically supported singularized and plural forms of attributes where appropriate, but from my experience that has lead to confusion when authoring pods for the first time.
One example is
s.framework = 'Foundation'
then as the library grows, they might add another framework like this:
s.framework = 'Foundation', 'AVFoundation'
and now things are confusing, because this actually works but it is not really clear why since there's another attribute called
Given that, I'd argue for the inverse of @kballard's suggestion: opt for keeping the DSL clear and explicit by supporting only the plural form
I'll once again suggest that CP should be able to more intelligently set the target Swift version based on the integrating project's version and the pod's versions, rather than just defaulting to the latest or requiring users who can't use the latest version to edit their Podfile with a
An additional issue is the possible confusion between the support for ranges in
@amorde Agreed overall with the intention. I don't think we want to dive into changing the DSL and its current semantics as part of this change.
We get lucky with this proposal because the
Singularization has no meaningful impact on the code design and it seems its pretty well handled internally. This is only a problem due to the initial version of
@jshier I'd like to hear more of your suggestion.
We can be doing some of that...but why? Shouldn't the pod author dictate the preferred version of Swift to compile their pod with?
The project based setting might not be sufficient to add version requirements although as I am typing this we could implicitly treat it as a requirement internally perhaps?
This sounds like a potential future enhancement to be done in the event that Apple introduces a version of the Swift compiler that is compatible with multiple Swift versions but does not allow mixing them.
At the moment, all released Swift compilers that support multiple Swift versions also support linking libraries/frameworks built with different supported Swift versions together.
I would advise against trying to design a system to handle incompatible Swift versions until we know how the compiler will handle this in the first place.
@dnkoutso, if I attempt to publish on trunk a podspec with
@Coeur you are correct, older versions of CocoaPods would not be able to accept a Podspec using DSL from the newer version.
One thing you can do is use the cocoapods_version attribute to specify that your Specification requires a certain version of CocoaPods to work properly.
Currently trunk will accept it as long as the version you are using to submit the Podspec supports the attribute
OK, so just to confirm, if I publish two podspecs with:
spec.version = '1.0.0'
spec.version = '1.0.1' spec.cocoapods_version = '>= 1.7.0' spec.swift_versions = ['4.0', '4.2', '5.0']
And if I do
And can I specify a beta version as the minimum version? Like:
@segiddins oh... then it will be problematic during the Beta period of 1.7.0, because pods owners testing/publishing updated podspec (with
We better either have an intermediate release of CocoaPods 1.6.1 that will simply accept and ignore the parameter