Today there is SwiftPM manifest API to set the minimum deployment target for each targeted Apple platform (macOS, iOS, tvOS, watchOS, visionOS, and DriverKit).
However, other platforms have somewhat similar concepts of minimum deployment target as well.
Windows in particular has the WINVER / _WIN32_WINNT macros and NTDDI version constants (see Update WINVER and _WIN32_WINNT | Microsoft Learn) which control which API is made available in the Windows SDK, and can help avoid issues of unconditionally using APIs from newer versions of Windows than you're intending to target.
We just ran into this recently in the Swift toolchain with the GetTempPath2W function, which was introduced in Windows 11, but Swift still supports Windows 10.
What do folks think of adding versioning constants to the SwiftPM "platforms" API for Windows? The granularity would be on the order of bi-annual Windows updates like 21H2, 22H2, etc., matching the NTDDI version constants. Especially looking for feedback from @compnerd here.
Having versioning on the SPM side as the named constants is reasonable. The problem is that they will not map to anything underneath. That is, we currently do not have availability attributes mapped in for Windows. I'd love to see that get added but for the language side, I feel like it is better to use the version numbers rather than the named constants.
This sounds preferable to me - using the named versions is going to be easier to work with for most users. I think that having them as aliases is reasonable so that people can still use the numeric values if they are inclined. But the documentation and examples should definitely prefer the named constants.
As to the duality between the versioned constraint vs the named constants, I believe that SPM is a higher level abstraction where it makes sense to have the simpler interface. However, for working with the API annotations, it is more convenient to work with the version number.
Swift code has a minimum version of 10.0.17763.0. The C/C++ compiler has no baseline - it is able to support pretty much anything down to Windows 95 (Windows 3.11 is difficult to mark as supported due to the possibility of needing/wanting 16-bit support which is not as well supported).