> On Jan 30, 2017, at 12:41 PM, David Sweeris via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Jan 24, 2017, at 10:18 AM, Daniel Dunbar <daniel_dun...@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
