Hi Jay,

> On Oct 16, 2016, at 7:14 PM, Jay Abbott <j...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

swift-evolution mailing list

Reply via email to