• What is your evaluation of the proposal?
+ 1
• Is the problem being addressed significant enough to warrant a
change to Swift?
Yes
• Does this proposal fit well with the feel and direction of Swift?
Yes
• If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
Yes. It's about the same.
• 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
A quick read.
On Mon, Jan 30, 2017 at 3: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.
>
> > • 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
