incompatible with Trio 0.10.0

[belm0]

... for no reason

trio>=0.9,<0.10

Should we relax it to trio>=0.9 rather than needing to push a new trio-websocket on every Trio release?

[mehaase]

Trio recommends pinning to a minor version: python-trio/trio#1

It also says that they intend to keep the x+1 minor version backwards compatible with x, so maybe the dependency should be trio>=0.9,<0.11? This would allow people to report deprecation warnings as soon as a Trio release comes out.

[belm0]

Trio recommends pinning to a minor version: python-trio/trio#1

Understood, but in practice this means that projects like mine can't upgrade Trio regular releases until trio-websocket maintainers get around to publishing a new release, and in most cases (> 85%?) the only change to websocket will be the dependency file. I think the trio-websocket project is too small for us to take on this maintenance burden.

In practice, any user of trio-websocket will also have a direct dependency on trio (for trio.run, etc.), and following trio's policy will itself have a pinned dependency on trio. So they'll be protected from sudden breakage. When they do attempt to upgrade trio, if it causes a build or runtime problem with trio-websocket they can simply revert the trio upgrade in their project and file a trio-websocket bug. Trio is still somewhat experimental (hence their policy), and transitively so is trio-websocket, so I think this is reasonable.

[njsmith]

The pinning recommendation was written very early on... maybe we should change it now that it's turned out that our backcompat story is not so trouble as all that

Though, we do have a likely break-the-world update coming up (the MultiError rewrite: python-trio/trio#611)