Although "not ship work in progress" has many advantages, it interferes with "staying very close to HEAD of our dependencies" as discussed in the https://aboodm

Although "not ship work in progress" has many advantages, it interferes with "staying very close to HEAD of our dependencies" as discussed in the https://aboodman.medium.com/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b https://aboodman.medium.com/in-march-2011-i-drafted-an-artic... post. In other words, if your code is being consumed by another project that has extremely good test coverage, and your HEAD changes, then they can manage the risk of proceeding - even if they have no a priori idea of whether your latest commit is for a standalone improvement, or whether your latest commit is disruptive unless the entire work-in-progress is consumed together. They may find that managing this risk is easier than managing the risk of "huge chunks of new code suddenly showing up."