Make dora node API minor versions compatible with one another.

[haixuanTao]

Describe the bug
Make dora API minor versions compatible with one another.

dora/binaries/daemon/src/node_communication/mod.rs

Lines 193 to 198 in dae290f

	} else {
	Err(format!(
	"version mismatch: node API v{node_api_version} is not compatible \
	with daemon v{daemon_version}"
	))
	};

Currently we force users to bump all existing dora node to use the latest API version. This can be challenging especially when using Rust where we need to modify a lot of Cargo.toml.

Could be good to have non breaking minor versions that are compatible with one another.

[phil-opp]

We're still at 0.3.4, so we treat minor version bumps as breaking changes (e.g. 0.3.4 -> 0.4.0). So I assume that you mean patch version bumps (e.g. 0.3.4 -> 0.3.5)?

I'm absolutely in favor of making the message formats between nodes, daemons, and the coordinator more stable and backwards compatible. However, changes to the message format become more difficult then because all non-compatible changes need to wait until 0.4.0 then.

Maybe we could move all the messaging types into a common sub-crate that we release and version independently of the main crates. This way, we could compare the versions of this sub-crate to check if messages are compatible, so we would be independent of the main version numbers.

[haixuanTao]

Yes patch version.

I think it's fine to have breaking patch version changes as we're still experimental, but the default should be to allow multiple versions for each daemon rather than defaulting to make an upgrade.

[phil-opp]

Then we need some kind of separate versioning as I proposed above. We need some way to figure out whether nodes/daemons/coordinator are compatible before trying to parse the messages.

[haixuanTao]

Ok, let's not reinvent the wheel, let's do:

• patch version are compatible with one another
• minor version introduce breaking changes

[phil-opp]

I think that's a good policy, but I'm not sure if we want to implement this just yet. We might still require some breaking changes to the message format in the near future, e.g. for #459. Right now we could implement this in a new patch version, but once we change our compatibility guarantee we would need to postpone such changes until we release the next minor version.