[swift-evolution] [swift-build-dev] [Review] SE-0135: Package Manager Support for Differentiating Packages by Swift version

[Daniel Dunbar]

Hi Max,

> On Aug 4, 2016, at 6:46 AM, Max Desiatov <max.desiatov at gmail.com> wrote:
> 
> Hi Daniel,
> 
> I hope this proposal really is still in active review, as it is marked as such in the swift-evolution Git repository.

It was supposed to close yesterday, but I haven't gotten to the paperwork. We have received very little feedback on the proposal so I appreciate your reply.

> I did a quick reading of this proposal and I like it very much. I think that it provides a solution that is additive and doesn't break any existing package specifications.
> 
> With the amount of source-breaking changes in Swift, I think this proposal is really important and I hope that it still will be implemented in Swift 3 timeframe. Especially as SwiftPM is not as tightly coupled with the core compiler infrastructure, this would be a good timing to introduce this to help people in transitioning from Swift 2.2 to Swift 3.
> 
> Have you previously considered also adding a field to manifests, that will allow to declare the supported version in the dependency manifest itself? As in:

We did consider this, but it has two major problems:

1. The list is cumbersome to maintain, particularly when the expectation is that new Swift versions do not break the package, and thus it remains compatible. A feature like this has the problem that once added, it requires maintenance in every package even once it has outlived its utility: As long as some package is used by SwiftPM-3.0 it has to keep the annotations, even if just to tell that version to look elsewhere.

2. This doesn't handle situations where we change the APIs within the manifest itself -- older SwiftPM versions won't be able to parse them and won't know what to do.

 - Daniel

> 
> let package =
> Package(
>    name: "Foo",
>    swiftVersions: ["3.0", "2.1"]
> )
> 
> This would make it impossible to even try to build this module with Swift 2.1, thus saving time by not doing a build that will inevitably fail. This would also help packages supporting both versions in the same source tree with #ifdef swift version conditionals. I do realise that my suggestion will not be considered for Swift 3, but I look forward to your feedback on this.
> 
> Thanks!
> 
> ---
> With best regards, Max.
> 
>> On 29 Jul 2016, at 21:36, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of "SE-0135: Package Manager Support for Differentiating Packages by Swift version" begins now and runs through August 3rd. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md
>> 
>> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-build-dev and swift-evolution mailing lists at
>> 
>> 	https://lists.swift.org/mailman/listinfo/swift-build-dev
>> 	https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> or, if you would like to keep your feedback private, directly to the review manager.
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and contribute to the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
>> 
>> 	* What is your evaluation of the proposal?
>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
>> 	* Does this proposal fit well with the feel and direction of Swift?
>> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> More information about the Swift evolution process is available at
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/process.md
>> 
>> Thank you,
>> 
>> - Daniel Dunbar
>> Review Manager
>> 
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>