build forward and backward compatibility into the protocol

[rade]

ATM weave peers must all be running the same version of the protocol; both sides of a new connection will shut it down when detecting that the protocol version of the remote peer differs from their own.

This makes upgrading weave when the protocol version has changed a major event.

We should build some mechanisms into the protocol for handling forward and backward compatibility.

Extracted from #403 (comment)

[rade]

Here's one way to do this...

The basic premise is that a particular version of weave has perfect knowledge of all the previously released versions and may contain special code to speak some such older versions. Peers could announce to each other what protocol versions they support, as part of the initial handshake. They would then pick the highest version supported by both, and communicate using that. If no such version can be found then the connection is closed and a suitable error logged, similar to what happens now when the protocol versions do not match.

[bboreham]

I would normally just have a bracket [oldest supported version, newest supported version], and you have to support everything in-between. Yes, a set is more general, but maybe YAGNI.

[rade]

Good point re oldest+newest. Perhaps we could even just stick to transmitting the newest version, as we do now, and leaving it up to the peer with the higher version to close the connection if the other peer's version is too old. I can think of two downsides:

• the lower-versioned peer won't be able to log an informative error message
• the higher-versioned peer might receive protocol messages it doesn't understand