search

dora-rs / dora

DORA (Dataflow-Oriented Robotic Application) is middleware designed to streamline and simplify the creation of AI-based robotic applications. It offers low latency, composable, and distributed dataflow capabilities. Applications are modeled as directed graphs, also referred to as pipelines.
https://dora-rs.ai
Apache License 2.0
1.35k stars 68 forks source link

Make dora node API minor versions compatible with one another. #504

Open haixuanTao opened 1 month ago

haixuanTao commented 1 month ago

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

https://github.com/dora-rs/dora/blob/dae290f83ced1f60c8f89e1ad1f5e0b0cfb37149/binaries/daemon/src/node_communication/mod.rs#L193-L198

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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

phil-opp commented 1 month ago

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.