[swift-evolution-announce] [swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard]

> On Jan 30, 2017, at 12:41 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Jan 24, 2017, at 10:18 AM, Daniel Dunbar <daniel_dunbar at apple.com> wrote:
>> 
>> Hello Swift community,
>> 
>> The review of SE-0150 “ Package Manager Support for branches" begins now and runs through January 31, 2017. The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.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. When replying, please try to keep the proposal link at the top of the message:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md
>> 
>> What goes into a review?
>> 
>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine 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?
> +1
> I would even go a bit further and suggest that "Package(url: String, branch: String)” should have “master” be the default value for `branch`, to make it simpler for small developer teams who don’t necessarily have all the collaboration issues of large projects.

This would make it easier to bring up your first set of packages without typing in as many parameters. But I have a couple concerns:

– A user who forgets to supply a second parameter could wind up accidentally depending on master when they didn't intend to. The normal case is to depend on a versioned tag, and we shouldn't make it too easy to mistakenly do otherwise.

– This would make it less obvious to someone reading a Package.swift manifest that a one of the dependencies is untagged. That's a potentially dangerous situation if you're not expecting it, so it should be visible, not implicit.

I think we should err on the side of making this explicit, since it is important, even if it means a little bit of extra typing when you're bringing up your first packages.

	- Rick

>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> IMHO, yes. Particularly since Xcode doesn’t support git tags (that I can find, anyway)
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> IMOH, yes. This proposal will make development with much easier for programmers whose work-flow is branch-based rather than tag-based.
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> An embarrassingly long time trying to figure out why a package wasn’t seeing changes I’d committed to one of its dependencies... Somewhere along the line I must’ve accidentally created a branch called “1.0.0”, which lead to me conflating the 1.0.0 tag with the 1.0.0 branch, which has caused me no end of head scratching.
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution