[swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar]

Hi Jay,

> On Oct 16, 2016, at 7:14 PM, Jay Abbott <jay at abbott.me.uk> wrote:
> 
> 
> 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...

I hope to tackle this through features which will help notify you when new versions you could upgrade to are available. I hope the default practice in the ecosystem will then become to heed those notifications and update.

> 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 <http://swift.org/> could host this for package owners, and usage stats for them too?

Both of the features you propose make a lot of sense to me, and are things I definitely would like to see us do in time.

For now, though, I see this feature as a "building block" towards those directions. Others can build on top of this feature to create automated systems like the ones you describe, I don't think we need to try and tackle everything ourselves in the initial proposal.

 - Daniel

> 
> On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161016/46311866/attachment.html>