[swift-build-dev] [swift-evolution] [swift-evolution-announce] [Review] SE-0145: Package Manager Version Pinning (Revised)

T.J. Usiyan griotspeak at gmail.com
Fri Dec 2 21:24:51 CST 2016

+1 Overall. I am not in favor of automatic pinning being the default
behavior but it isn't such a big issue.

On Fri, Dec 2, 2016 at 12:18 PM, Anders Bertelrud via swift-evolution <
swift-evolution at swift.org> wrote:

> On 2016-11-28, at 09.44, David Sweeris via swift-build-dev <
> swift-build-dev at swift.org> wrote:
> Does the pinning info have to be in an optional file? Would it be better
> to have it be an optional part of the manifest? There'd be one less file to
> carry around.
> One conceptual reason to keep the pinning information in a separate file
> is that, while a manifest is a single source of truth for the inherent
> dependencies of a single package, a pin file expresses contextual
> constraints about a package graph as a whole.  The fact that the
> information in the pin file is context-based also leads to a second big
> reason to keep them separate:  it would be perfectly reasonable to have
> multiple pin files for the same top-level package, for example in the case
> of CI systems that should test against the latest release versions of
> dependencies as well as the latest pre-releases (for example).  There would
> need to be additional facilities for this to work well, but the design
> should not preclude the use of multiple pin files in the future, and
> storing multiple sets of pinning info in the manifest would make that
> harder.
> Anders
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161202/e418674f/attachment.html>

More information about the swift-build-dev mailing list