Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
haixuanTao opened this issue May 21, 2024 · 5 comments · Fixed by #614
Closed

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

haixuanTao opened this issue May 21, 2024 · 5 comments · Fixed by #614
Labels
bug Something isn't working daemon

Comments

@haixuanTao
Copy link
Collaborator

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

} 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.

@github-actions github-actions bot added bug Something isn't working daemon labels May 21, 2024
@phil-opp
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Collaborator

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
Copy link
Collaborator Author

haixuanTao commented May 22, 2024

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

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

@phil-opp
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working daemon
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants