title: What exactly is considered a breaking change to a library crate?
body: <p>Rust crates use <a href="http://semver.org/" rel="noreferrer">Semantic Versioning</a>. As a consequence, each release with a breaking change should result in a major version bump. A <em>breaking change</em> is commonly considered something that may break downstream crates (code the depends on the library in question).</p>
  
  <p>However, in Rust a whole lot has the potential of breaking downstream crates. For example, changing (including merely <em>adding to</em>) the set of public symbols is possibly a breaking change, because downstream crates can use glob-imports (<code>use foo::*;</code>) to pull symbols of our library into their namespace. Thus, adding symbols can break dependent crates as well; see <a href="https://play.rust-lang.org/?gist=991c179b87404188ff8cc18c75f66d4d&amp;version=nightly&amp;backtrace=0" rel="noreferrer">this example</a>. </p>
  
  <p>Similarly, changing (adding or changing the version) the set of <em>our</em> dependencies can break downstream builds. You can also imagine that the downstream crate relies on a specific size of one of our public types. This is rarely, if at all, useful; I just want to show: everything could be a breaking change, if only the downstream crate tries hard enough. </p>
  
  <p>Is there any guideline about this? <strong>What exactly is considered a breaking change and what not (because it's considered "the user's fault")?</strong></p>