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

[Martin Waitz]

Hello,

Am 2016-11-24 13:54, schrieb Alex Blewitt via swift-evolution:
> At the moment, the proposal suggests having a secondary 'pins' file,
> which exists to allow explicit dependencies to be checked in to
> version control. This can be done at the moment, using a
> Version(1,2,3) or range Version(1,2,3)...Version(1.2.3) in the
> constraints.
> 
> What the proposal doesn't bring forward clearly is the versioning of
> transitive dependencies, and whether or not those dependencies violate
> the requirement constraints. For example, if A depends on B, and B
> depends on C version 1.2.3+, can or should A pin C version 0.9.9? What
> if A depends on B and D, both of which depend on different versions of
> C that may be semantically equivalent (e.g. C version 1.2.3 and C
> version 1.4.5)? This will come up more often than the 'fail to build'
> approach outlined in the proposal.

be careful and do not mix up `Package.swift` and `Package.pins`.

Both are used for different things:
  * Package.swift is used to specify compatible versions of dependencies.
    These always apply.
    In your example above, a `swift update` would need to find a set of 
versions
    for B, C, and D where all these version requirements are met.
    Therefor, Package.swift ranges should be as broad as possible,
    to make it possible to find compatible versions.
  * Package.pins stores the current set of all (transitive) dependencies.
    It is stored in the toplevel project (A) and would pin one set of 
compatible
    (and hopefully tested) versions of B, C and D.
    This way you always get a clean state when you start working on A.

Then, when you run `swift package update` in A, it will try to find a 
newer set of
B, C, and D, by looking at all of the `Package.swift` files.
This new set will then be written to `Package.pins` so that everybody 
can benefit from the update.
It's important to not hard-code specific versions into `Package.swift` 
as this complicates the version resolution during update and could lead 
to the conflicting version requirements you describe.

-- 
Martin