As part of establishing a 1.0 release (#1361), I want to write down our policy and process for breaking changes.

The basic policy and procedure I'm leaning towards is something like:

In order to introduce a breaking change, the breaking behavior must (when reasonably possible)
be opt-in in the first release (N) it's available for.

The basic idea is: it's easier to handle breaking changes when you can incrementally upgrade a code base. e.g., upgrade the dependency version N, update apis to the new version's requirements, then upgrade the dependency to N+1.

I'm not keen on a date-based scheme (e.g. an incompatible change must retain a compatible option for 6 months); I'd rather just use version releases.

I'm torn about what happens after that, though. I see two approaches:

• The next release forces the new behavior on; the toggle is a no-op or removed. This has the advantage of being easier on us maintainers; defunct code sticks around for less longer.
• The next release enables the new behavior by default, but users are able to opt-out. The release after that one forces the new behavior on. This has the advantage of being easier for users (you can opt-out problem cases reactively to more clearly identify what needs to be fixed). But, I suspect most people won't notice an incompatible change until it's the default behavior, so I'm not sure how much value the extra step really has. This is a bit more of a burden on us maintainers, though.