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

Max Desiatov max.desiatov at gmail.com
Thu Aug 4 08:46:05 CDT 2016


Hi Daniel,

I hope this proposal really is still in active review, as it is marked as such in the swift-evolution Git repository.

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:

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



More information about the swift-build-dev mailing list