Adjust SwiftPM 5.7 to minimum supported deployment target changes

[neonichu]

Update minimum supported deployment targets and mark older version constants as deprecated in tools-version 5.7.

If a package specifies a custom deployment target older than the minimum, the derived one in the model will be automatically raised, similar to how it was alreaady being done for test targets.

rdar://93920177

Motivation:

Xcode 14.0 is raising the minimum supported deployment target versions for most platforms.

[neonichu]

@swift-ci please smoke test

[neonichu]

Not 100% sure I caught all the tests that need updating since I am still seeing the _StringProcessing thing locally 😬

[neonichu]

error: the library 'TSCBasic' requires macos 10.10, but depends on the product 'SystemPackage' which requires macos 10.13; consider changing the library 'TSCBasic' to require macos 10.13 or later, or the product 'SystemPackage' to require macos 10.10 or earlier.

[neonichu]

Probably an issue with TSC explicitly declaring a 10.10 deployment target: https://github.com/apple/swift-tools-support-core/blob/main/Package.swift#L21

[neonichu]

swiftlang/swift-tools-support-core#329
@swift-ci please smoke test

[neonichu]

I wonder whether that means that we have to do something where the raised minimum is for tools-version 5.7 only or we have to adjust these checks to not enforce the minimum?

Otherwise I can see a scenario where an existing package declares e.g. macOS 10.12 as its deployment target and depends on a package that doesn't declare one. With the raised deployment target, the dependency will implicitly have a 10.13 minimum deployment target, so the check will fail and prevent building at all where otherwise there may have been a build time warning, but XCBuild would implicitly raise both to 10.13 anyway.

[abertelrud]

I wonder whether that means that we have to do something where the raised minimum is for tools-version 5.7 only or we have to adjust these checks to not enforce the minimum?

Otherwise I can see a scenario where an existing package declares e.g. macOS 10.12 as its deployment target and depends on a package that doesn't declare one. With the raised deployment target, the dependency will implicitly have a 10.13 minimum deployment target, so the check will fail and prevent building at all where otherwise there may have been a build time warning, but XCBuild would implicitly raise both to 10.13 anyway.

Right, it sounds as if the comparison should be on the adjusted minimum deployment target. I guess that could make the error confusing if the package claims one thing but then the error is about a higher version.

[neonichu]

A few tests are hitting exactly this situation:

error: the executable 'Dealer' requires macos 10.12, but depends on the product 'DeckOfPlayingCards' which requires macos 10.13; consider changing the executable 'Dealer' to require macos 10.13 or later, or the product 'DeckOfPlayingCards' to require macos 10.12 or earlier.

[neonichu]

@swift-ci please smoke test

[neonichu]

@swift-ci please smoke test

[abertelrud]

Updated change looks reasonable to me and is about all that can be done if the toolchain doesn't support the older minimum deployment target (short of just refusing to build the package, which I think would be unfriendly and probably not what people usually want).

SwiftPM could emit a warning but then there wouldn't be a way to get rid of it short of forking the package and adding annotations, so maybe that's not a good idea either.

[neonichu]

Updated now to automatically raise the derived deployment target to the minimum. We could consider emitting a warning if the specified deployment target is lower than the minimum, but I am not sure if that would be annoying in practice.

If a package is using the 5.7 tools-version, using an older deployment target will already show a deprecation warning after these changes, so a secondary warning seems redundant.

If a package is using an older tools-version, it might be desired to support older deployment targets if older tools are used, so the author would end up with an unfixable warning in 5.7.

The only case that actually seems interesting is executables, because the author may want to legitimately deploy to older versions of macOS and may have missed that those are not supported anymore, so the warning could be useful.

[abertelrud]

Some good points there about a warning — I think that there are a lot of subtle traps with adding a warning, and we can hold off and see if one should be added later.

[saagarjha]

I work on a project that uses a new version of SPM but needs to deploy back to older platforms. I understand that this is no longer officially supported but in practice everything "works"…except for this check, which forces the deployment target up. I'd be interested in seeing if we could turn off this behavior on an opt-in basis. Happy to eat a warning too if need be.

What I was thinking was I could specify a target with all my dependencies in it, and explicitly specify a string version (e.g. MacOSVersion(string: "10.11"), rather than MacOSVersion.v10_11. If I spell it out explicitly it seems reasonable to me that I know what I'm doing and would not like this adjustment to be performed. Thus, my package (and its dependencies) would build with that platform version, rather than having the version automatically raised. Does this sound reasonable?