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

[Rob Allen]

I appreciate that I'm late on this, but I'm on vacation. 


> On 29 Jul 2016, at 20:36, Daniel Dunbar via swift-evolution <swift-evolution 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?

The solution is quite clear. I particularly like the concept of version specific git tags. I'm less keen on version specific Package.swift files as I feel that tags are meta data, but Package.swift isn't.

Personally, I'd prefer to only have version specific git tags, but acknowledge that version-specific Package.swift files simplify the work for some package maintainers. If you need different source code in Package.swift and #if doesn't work, then I feel that you should use version specific git tags as you would do for the rest of your code.

I'm pleased that this proposal is backwards compatible as both options can be completely ignored for packages that don't need it. 

On the whole, +1.


> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Most definitely.

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

It certainly acknowledges the current state of Swift language differences :)

> 	* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

This is quite elegant and more flexible than what I've seen elsewhere.

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

I read the proposal in detail.

Regards,

Rob..