[swift-evolution] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)
daniel_dunbar at apple.com
Mon Dec 5 10:46:12 CST 2016
> On Dec 1, 2016, at 1:42 PM, Alexis via swift-evolution <swift-evolution at swift.org> wrote:
> Haven’t had a chance to catch up on the latest discussion, but I just saw that the Yarn developers posted an excellent piece on lockfiles this week:
> https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all <https://yarnpkg.com/blog/2016/11/24/lockfiles-for-all>
> They argue lockfiles should be commited by libraries (but still ignored by applications). The essential point is that this makes it easier for developers of the library to maintain a coherent build of the library when dependencies ship a bug. The focus is particularly on new developers, who would otherwise lack a lock file.
This post does not acknowledge the social and cultural engineering impact of this policy contributing to a lessening of conformance to semantic versioning. I still believe such an effect will happenl, and that it will have negative repercussions for the ecosystem. I am willing to be convinced (and hopefully am wrong), but I find any post which doesn't acknowledge the potential for this an incomplete argument.
I will also point at that we have `package edit` as a top-level feature exactly to enable the downstream developer contribution behavior in a way which avoids the problem this blog post is referencing.
>> On Nov 20, 2016, at 12:48 AM, Anders Bertelrud <anders at apple.com <mailto:anders at apple.com>> 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-build-dev>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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 <https://github.com/apple/swift-evolution/blob/master/process.md>
>> Thank you,
>> Anders Bertelrud
>> Review Manager
>> swift-evolution-announce mailing list
>> swift-evolution-announce at swift.org <mailto:swift-evolution-announce at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution