[swift-build-dev] [swift-evolution] Proposal: Package Manager Version Pinning

Paul Cantrell cantrell at pobox.com
Fri Oct 14 18:02:29 CDT 2016

Sorry for the late arrival to this thread. Comments below…

> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev <swift-build-dev at swift.org> wrote:
> What this proposal about is in one sense being able to export and share those pins.

This is a crucial and clarifying insight. It should be in the proposal! Near the top.

> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default.

Indeed. Pins should be only be about sharing specific versions within a development team — not with client packages / apps. What’s pinned in Vegas stays in Vegas. Publishing pins to other projects would be nonsensical.

> 5. Given that many people agree there are two workflows (we ourselves had talked about this a lot when writing the proposal, but didn't put it in), we felt it makes sense to consider adding that as an explicit declaration *somewhere*.
> @Eloy, @Orta: Suppose we had a semantic notion of which packages were intended to be "top-level" versus used as a dependency, and we chose our defaults accordingly (in this case, we would orient workflows towards pinning by default in the top-level case, in the used as a dependency case we would orient away from it, e.g. warning you if you checked it in). What would you think of such a design?

I’m puzzled. If a package’s pinning does not affect any other package that uses it, why should the defaults be different? A library will still suffer from all the “works for me” problems an app might.

Is the rationale that not pinning libraries encourages accidental testing of new versions of a library’s dependencies as they arrive? Or is there another rationale for having different defaults?

Cheers, P

More information about the swift-build-dev mailing list