Package resolution does not use minimum supported platform version when determining dependency version

[vashworth]

Is it reproducible with SwiftPM command-line tools: swift build, swift test, swift package etc?

• Confirmed reproduction steps with SwiftPM CLI. The description text must include reproduction steps with either of command-line SwiftPM commands, swift build, swift test, swift package etc.

Description

I have a package that supports iOS 14+. I want to use a dependency (https://github.com/googlemaps/ios-maps-sdk, for example) and give it a range of versions, such as "8.4.0"..<"10.0.0". It should use a version within that range that also supports iOS 14 if there is one. See "Steps to reproduce" below for more information.

Expected behavior

I expect it to use a version of the dependency that also supports iOS 14.

Actual behavior

It uses the latest version, which only supports iOS 15.

Steps to reproduce

1. mkdir BadVersioningResolution
2. cd BadVersioningResolution/
3. swift package init --name BadVersioningResolution
4. Edit the Package.swift to do the following:

• Set the minimum support iOS version to 14
• Add a dependency on https://github.com/googlemaps/ios-maps-sdk

// swift-tools-version: 6.0
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "BadVersioningResolution",
    platforms: [.iOS(.v14)],
    products: [
        // Products define the executables and libraries a package produces, making them visible to other packages.
        .library(
            name: "BadVersioningResolution",
            targets: ["BadVersioningResolution"]),
    ],
    dependencies: [
        .package(url: "https://github.com/googlemaps/ios-maps-sdk", "8.4.0"..<"10.0.0"),
    ],
    targets: [
        // Targets are the basic building blocks of a package, defining a module or a test suite.
        // Targets can depend on other targets in this package and products from dependencies.
        .target(
            name: "BadVersioningResolution",
            dependencies: [
                .product(name: "GoogleMaps", package: "ios-maps-sdk"),
            ]),
        .testTarget(
            name: "BadVersioningResolutionTests",
            dependencies: ["BadVersioningResolution"]
        ),
    ]
)

Note the range is "8.4.0"..<"10.0.0". Version 8.4.0 support iOS 14. However, version 9.4.0 support iOS 15.

5. swift package show-dependencies

Fetching https://github.com/googlemaps/ios-maps-sdk
Fetched https://github.com/googlemaps/ios-maps-sdk from cache (0.88s)
Computing version for https://github.com/googlemaps/ios-maps-sdk
Computed https://github.com/googlemaps/ios-maps-sdk at 9.4.0 (0.48s)
Creating working copy for https://github.com/googlemaps/ios-maps-sdk
Working copy of https://github.com/googlemaps/ios-maps-sdk resolved at 9.4.0
Fetching binary artifact https://dl.google.com/geosdk/swiftpm/9.4.0/GoogleMaps_3p.xcframework.zip from cache
Fetched https://dl.google.com/geosdk/swiftpm/9.4.0/GoogleMaps_3p.xcframework.zip from cache (0.95s)
.
└── ios-maps-sdk<https://github.com/googlemaps/ios-maps-sdk@9.4.0>

When you run this, you can see that the ios-maps-sdk package resolved to 9.4.0 rather than 8.4.0 even though 9.4.0 does not support iOS 14. It should have used version 8.4.0, which does support iOS 14.

Swift Package Manager version/commit hash

Swift Package Manager - Swift 6.0.3

Swift & OS version (output of swift --version ; uname -a)

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx15.0

[stuartmorgan-g]

Notably, CocoaPods has the behavior described here of incorporating min OS version into the version resolution, so for packages in the CocoaPods ecosystem that relied on this functionality, this is a regression when moving to SPM.

[dschaefer2]

I've seen this request in other places as well. I think the biggest hurdle is that the platform versions are in the package manifest. That would mean we would have to checkout each version under consideration and parse the manifest to consider it in resolution. This could greatly slow down resolution time.