<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><div>Hi Jay,</div><div><br class=""></div><blockquote type="cite" class=""><div class="">On Oct 16, 2016, at 7:14 PM, Jay Abbott <<a href="mailto:jay@abbott.me.uk" class="">jay@abbott.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>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...<br class="gmail_msg"></div></div></div></div></div></div></div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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:<br class="gmail_msg"><br class="gmail_msg"></div>* Build a list of dependencies that can potentially be updated (from the entire dependency graph).<br class="gmail_msg"></div>* For each updatable dependency in the list {<br class="gmail_msg"> * Keep all the other pins as-they-were and fetch the updated dependency.<br class="gmail_msg"></div> * Build the project and run its tests.<br class="gmail_msg"></div><div class="gmail_msg"> * Keep track of which ones worked and which ones failed.<br class="gmail_msg"></div><div class="gmail_msg">}<br class="gmail_msg"></div>* If there are updatable dependencies that build successfully, and all (your project) tests still pass - this can to be reported to the development team.<br class="gmail_msg"></div><br class="gmail_msg">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.<br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">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 <a href="http://swift.org/" class="gmail_msg" target="_blank">swift.org</a> could host this for package owners, and usage
stats for them too?<br class="gmail_msg"></div></div></div></div></div></blockquote><div><br class=""></div></div><div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> In Swift, we have pretty consistently tried to choose the "right" answer to make the resulting language consistent and beautiful.<br class="gmail_msg">
> 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.<br class="gmail_msg">
<br class="gmail_msg">
+100<br class="gmail_msg">
<br class="gmail_msg">
Moreover, after your explanation, `lock` feels wrong to me too.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>
</div></blockquote></div><br class=""></body></html>