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 new Package*.swiftwhen thePackageDescription` picks up something new that they want to make use of.