> On Nov 28, 2016, at 8:25 PM, Paul Cantrell via swift-evolution > <swift-evolution@swift.org> wrote: > > Just a quick mini-review here; sorry, time pressure. > > This version of the proposal seems acceptable to me, though I have a nagging > feel that it’s more complex than it needs to be.
I agree with this feeling, but am not sure how much it will matter in practice. > In particular, the two modes (autopin enabled / disabled) plus the --repin > option seem to me to have a high confusion:benefit ratio. I can imagine a > much simpler model in which: > > general behavior is always like --enable-autopin, > update always acts as if --repin is specified, and > .gitignore is the sole difference in how pinning behaves for different > projects. > > What is the benefit of the proposal’s more complex model? AFAICT, the one > thing this simpler model wouldn’t allow is for a team to share pinned > versions of some individual ill-behaved dependencies without pinning all of > them. If that’s the only missing behavior, my gut tells me there’s a way to > do that with less cognitive burden on SwiftPM users. (Are there other > benefits to the proposal’s model that I’m missing?) This is a benefit I *really* want to retain, because we continue to feel it is important for people not to overly constraint the dependency graph, and I still feel this is the right model for users to follow (pin problematic dependencies, not everything). I really want to retain the technical ability to do it, even if it is off by default. If you have a concrete proposal on a better way to implement this I would love to hear it. > Those concerns stated, I’d be fine with the proposal as stated. It would > accommodate all the different ways I can imagine using SwiftPM on my own > projects. It might be confusing to newcomers, but it won’t be a roadblock for > getting work done. At this point, what I want to do is get this implemented and in a usable state, and then gauge how problematic this behavior difference is. If it is a source of confusion, then we should iterate to try and address it. - Daniel > > Cheers, > > Paul > > >> On Nov 19, 2016, at 11:48 PM, Anders Bertelrud via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hello Swift community, >> >> The review of "SE-0145: Package Manager Version Pinning" begins again after >> revisions, starting now and running through November 28th. The proposal is >> available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.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, >> >> Anders Bertelrud >> Review Manager >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
