Unnecessary bump to 1.0.0 when dealing with peer deps and 0.x versions

[jakubmazanec]

Affected Packages

TBH I'm not sure which package handles this. @changesets/assemble-release-plan?

Problem

There are two packages in a monorepo, foo and bar. Notice that their version have major version 0 and that bar depends on foo via peer dependnecy:

{
  "name": "foo",
  "version": "0.1.0"
}

{
  "name": "bar",
  "version": "0.1.0",
  "peerDependencies": {
    "foo": "^0.1.0"
  }
}

Let's create new changeset:

---
'foo': minor
---
New feature makes Foo better!

When running npx changeset version, foo is bumped to 0.2.0, that means peer dependency in bar/package.json must change to ^0.2.0, which is a breaking change (because that's how caret ranges work in https://www.npmjs.com/package/semver), so bar version is bumped too - to 1.0.0. But since we're still in 0.x versions, bumping bar to 0.2.0 would suffice (it is allowed to make breaking changes when major version is zero according to https://semver.org/).

Proposed solution

In this situation, bar is bumped to 0.2.0, not 1.0.0.

[R-Bower]

Related: #1011

[theoephraim]

OK so there is a larger problem around these bumps in general BUT today I learned that in semver v0 has different treatment.
The ^ operator on any v0 version has the same behaviour as ~

concretely:
^0.2.3 = >=0.2.3 || <0.3 <- WTF
^1.2.3 = >=1.2.3 || <2 <- what I think most people expect

So a minor version bump on a 0.x package will (unexpectedly) trigger a bump on dependency that is using ^