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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-build-dev
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
