swiftLanguageVersions best practices for libraries

The thread on RFC: Tools version with version-specific manifests got me thinking about how to shuffle the Package.swift files for swift-protobuf, and it got me thinking about the swiftLanguageVersions again.

The enum has explicit cases for things it knows about, and .v5 has been added to master -

But if I wanted to declare support, I'd need to make a Package@swift-4.2.swift and move the Package.swift to swift-tools-version:5.0 just to use the .v5 value. So if we keep adding .v* cases with each Swift release it also means a library would have to add a new Package@-swift#.# just to use that new constant. i.e. - it seems like we're causing an explosion of Package*.swift files to express support for multiple language versions.

Would be better to stop using the .v* cases, and instead suggest libraries use the .version(string) form so their Package.swift could say stay on 4.2, but swiftLanguageVersions could end up with a value like: [.v3, v4, v4_2, .version("5.0"), .version("5.1")]" (etc)? That way they can always add support for the new Swift language version without having to keep duplicating the Package.swift to bump the tools version. They'd only have to make a newPackage*.swiftwhen thePackageDescription` picks up something new that they want to make use of.

1 Like

Right, that's the whole point of .version(String). The typed API is useful if you're already using the new tools version but otherwise you should use the .version(String) to avoid bumping your manifest's tools version.

Good to hear I'm following correctly, but I'd suggest the docs and maybe in the eunm's decl that this get call out so it leads developers in the correct direction.

2 Likes
Terms of Service

Privacy Policy

Cookie Policy