Publish new minor version

[feross]

Following on my comment here: #250 (comment)

Usually, whenever I make a breaking change, I make the commit message start with BREAKING: so that users upgrading to the new major version can quickly scan for the breaking commit. In that commit, I write what is breaking and what (if anything) the user can do to migrate.

@rationalcoding Can you write up a description and rationale for the breakage?

Once this is documented here, I can release a new major version and include the message in the version commit, which will be fine for this release.

[feross]

Sidenote: this might cause serious issues for WebTorrent clients since I can't force update the hundreds of websites that already have the WebTorrent library on them. It sounds like peers with a newer simple-peer won't be able to talk to the old ones?

[t-mullen]

This renegotiate signal event is only sent if renegotiation is used. It is disabled by default and shouldn't cause issues for WebTorrent if the new features are never used by any WebTorrent peers.

[t-mullen]

Just never use peer.negotiate(), peer.addTrack(), or peer.addStream() and everything will work fine. If a peer DOES use one of those events, remote peers will crash.

This could be considered semvar minor if the entire network doesn't use the new feature. Using the original featureset will work fine with old peers.

[t-mullen]

Now that I'm thinking about it, this would be semvar minor. When not using the new renegotiation or multi-streaming features, interop works perfectly fine with older versions. Only when using new features does backward compatibility break.

[feross]

Nice, thanks for the explanation. I'll release this as a minor version then.

[feross]

Will publish when master is passing on CI, just waiting for it...

[feross]

Not passing, still blocked on #283

[feross]

Published 9.1.0! Thanks @rationalcoding!