matrixorigin / matrixorigin/matrixone

[Tech Request]: API compatibility between components of different versions

Open
#11,781 0 comments 0 reactions 1 assignee Assigned to @XuPeng-SH View on GitHub
kind/tech-request priority/p0.5
Dominant language
Go
Stars
1.9k
Forks
311
Avg merge
1d 3h
Merged PRs (30d)
768

Description

### Is there an existing issue for the same feature request?

- [X] I have checked the existing issues.

### Is your feature request related to a problem?

```Markdown
There are inevitable cases (some are desired, actually) that components will run in different versions:

1. Rolling-update/Rollback: old version and new version will coexist in the cluster, suppose we upgrade the cluster from version A to B, API compatibility between A and B must be ensured;
2. Multi-tenant: CNs are dedicated to tenant, different tenants may run different CN versions. However, TN is shared so CN/TN version is inevitably different;
3. Proxy: proxy is also shared by tenants, and for to keep the sql session alive, minimize the number of proxy upgrades, while periodic CN feature upgrades goes, proxy <-> CN compatibility is required;
```

### Describe the feature you'd like

Add version to all RPC and storage encodings, define the compatibility rule and able to print current version that would be used by a `mo-service` binary, for example

```
./mo-service --version
binary version: v1.0.0-rc1
protocols:
object: v3.0.0
checkpoint: v7.0.0
...
```

Note: for version change that breaks backward/forward compatibility, https://github.com/matrixorigin/matrixone/issues/12150 would help to make the encoding version is coherent at cluster level:

### Describe implementation you've considered

_No response_

### Documentation, Adoption, Use Case, Migration Strategy

_No response_

### Additional information

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.