@jspahrsummers this was originally a task created by you, before moving it over.

I don't like using semver for wire protocols. My reason is very similar to this discussion on Etherium: libp2p/specs#203

Semver adds complexity by requiring all clients and servers to correctly deal with it, effectively forcing them to take a dependency (assuming they don't use an SDK).
Even between two patch version with backwards compatibility it's not clear what the implications of an added optional field are at a given time, and they might widely vary between different types of changes. The result of two clients with different versions is unpredictable, particularly if you consider the combinatorial explosion over multiple versions.
This assumes that we get it right to adhere to semver, which historically all projects have struggled with and broken at some point or another.

I think the right approach here is allowing clients and servers to negotiate over a range over versions instead of a single version, but still making each version a simple monotonically increasing integer. This means client A can advertise version [1,2,3] whereas server B can say it only speaks [1,2]. Of course this would still add a lot of complexity on clients that want to support multiple versions, but i think that's okay, at least in that case they must make the implications explicit in code.

Protocol version should be a string, not an int #1

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions