<div dir="ltr"><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&#39;s going on with external dependencies. Although this gives me a separate idea...<br class="gmail_msg"><br 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&#39;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&#39;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><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 &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; 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">&gt; In Swift, we have pretty consistently tried to choose the &quot;right&quot; answer to make the resulting language consistent and beautiful.<br class="gmail_msg">
&gt; I&#39;m perfectly happy to have a discussion about the naming, but I would like it to be driven by what we believe the &quot;right&quot; 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>