<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Example: say I have an ecosystem of 10 packages. A-J. And they do a<br>
release every 6 months that is guaranteed to work together, but every<br>
time some issue occurs which ends up clamping the group together- e.g.<br>
an external release breaks API and so A1s deps are disjoint with A2s,<br>
and then the same between A2 and A3. Even though A1's API is<br>
compatible with B2's: its not internal bad code, its just taking *one*<br>
external dep breaking its API.<br>
<br>
After 2 releases you have 10^2 combinations, but only 4 are valid at<br>
all. Thats 4%. 8 releases gets you 10^8, 8 valid combinations, or<br>
0.0000008%.</blockquote><div><br></div><div>Yes, so this would not be a situation where "conflicts do not exist (or are very rare)" as my post mentioned.  Is this rate of conflicts something you measured or is it a value you made up?  </div><div><br></div><div><br></div><div>I don't hear anyone arguing that the status quo makes sense.  I think we're mostly just chatting about the right thing to optimize the solution for and what sorts of short cuts may be useful (or even necessary).  Since we can measure the actual conflict and other values in practice, data seems like it may be a good path toward grounding the discussion...</div><div><br></div><div>Thanks,</div><div>Justin</div></div></div></div>