SE-0236: Package Manager Platform Deployment Settings

[pvieito (Pedro José Pereira Vieito)]

Yes, I like this middle ground approach where excluding a platform requires explicitly specifying it.

It encourages packages were all platforms are supported while allowing restricting the supported OSs.

[Aciid (Ankit Aggarwal)]

@owensd

it seems like the primary goals are:

1. Allow developers to specific a minimum platform version
2. Promote packages to be available for all platforms
3. Allow for new platforms to be added by default to all packages
4. Allow developers to specify that only certain platforms are supported

I think this nicely summarizes the high level goals of this feature!

@owensd

To me, this implies that platforms should only provide a mechanism for changing the default value for the minimum version.

So:

    platforms: [
       .macOS(.v10_13), .iOS(.v12)
    ]

Would mean that all platforms are supported, but macOS and iOS have version v10.13 and v12 as the deployment targets set.

This solves #1, #2, and #3 above.

Agreed. This seems like the most sensible default to me.

@owensd

Allowing developers to restrict platforms is a different goal that updating the minimum supported version. As such, I think it would be best to be a separate option (and frankly, outside of this particular proposal):

I also want to separate out that part into a different proposal but I don't agree that it should be a different option. I feel like it should be part of the main platforms API.

Maybe something like:

platforms: .platforms([.macOS(.v10_13), .iOS(.v12)], restricted: true)

restricted=true would mean: allow all listed platforms + any platform not known to the current tools version. This will solve #1, #3, #4 and enable restricting to a particular set of platforms while allowing bringing up new platforms.

With this approach, we don't require .unsupported and it will lead to a much cleaner API. Having to explicitly mark platforms as unsupported seems counter-intuitive and can lead to a massive list of platforms as support for Swift grows over time.

[owensd (David Owens II)]

@Aciid

restricted=true would mean: allow all listed platforms + any platform not known to the current tools version. This will solve #1, #3, #4 and enable restricting to a particular set of platforms while allowing bringing up new platforms.

I think this is a reasonable trade-off. I’d like to see platforms be more data-driven in the future, but I think this pattern still works fine there too.

[johannesweiss]

What is your evaluation of the proposal?

+1

Is the problem being addressed significant enough to warrant a change to the Swift Package Manager?

Yes, right now swift-nio-transport-services is really annoying to compile (need to pass -X... flags) and this proposal will resolve this, awesome!

Does this proposal fit well with the feel and direction of Swift?

Totally

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal, most comments and chatted with Cory.

[NeoNacho (Boris Buegling)]

The review of SE-0236: Package Manager Platform Deployment Settings ran from November 14th through November 26th, 2018. There was a lot of feedback, and the proposal is accepted with modifications. Thanks to everyone who participated!

Boris Buegling
Review Manager

[johannesweiss]