[swift-evolution] Proposal: Package Manager Version Pinning

[Jay Abbott]

I like the core idea here, but I feel that it could potentially prevent
teams updating, through focus on other things and general
laziness/ignorance to what's going on with external dependencies. Although
this gives me a separate idea...

How about an additional feature that can be run manually if desired, or
more likely run as a daily/overnight job on CI. I'm not entirely sure what
the command would be or how it would work exactly, but the general idea
would be:

* Build a list of dependencies that can potentially be updated (from the
entire dependency graph).
* For each updatable dependency in the list {
    * Keep all the other pins as-they-were and fetch the updated dependency.
    * Build the project and run its tests.
    * Keep track of which ones worked and which ones failed.
}
* If there are updatable dependencies that build successfully, and all
(your project) tests still pass - this can to be reported to the
development team.

This way, teams could use pinning and automate checking for compatible
updates. Also package owners could potentially be notified (with explicit
consent of their users) if they broke compatibility in what should have
been a compatible release. I realise that not everything going on here is
inside the remit of a package manager, but the package manager could
provide functionality to help with such things, a bit like git-bisect. Then
again, the SPM community proposal seems to cast quite a wide potential
remit.

An additional cool feature would be some mechanism to allow notifications
to the package owner if what they have released as compatible (according to
the version) actually isn't. Explicit opt-in from users for this one of
course, with options for what information to include. Maybe swift.org could
host this for package owners, and usage stats for them too?

On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution <
swift-evolution at swift.org> wrote:

> In Swift, we have pretty consistently tried to choose the "right" answer
to make the resulting language consistent and beautiful.
> I'm perfectly happy to have a discussion about the naming, but I would
like it to be driven by what we believe the "right" answer is, not simply
by deference to existing solutions.

+100

Moreover, after your explanation, `lock` feels wrong to me too.
_______________________________________________
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-evolution/attachments/20161017/2a51248f/attachment.html>