Search before asking
Motivation
There's currently no way to retrieve a human-readable Fluss version string from a running cluster via the client API. apiVersions() is a gateway-level RPC (not on Admin) and returns only protocol api_key/min/max numbers plus server_type — no semantic version like 0.9.0 or 0.10.1.
Any tool built on top of Fluss (a CLI, a UI, a monitoring agent) that wants to display which Fluss version a cluster is running — or that needs to adapt its own behavior to what a given server version actually supports (for example, the alterable table-property allow-list in FlussConfigUtils.isAlterableTableOption differs across versions) — currently has no way to query this from the server itself; it has to be supplied out-of-band by whoever operates the cluster.
Solution
Add a way to retrieve the running server's version string, for example:
- A new
Admin method, e.g. CompletableFuture<String> getClusterVersion(), backed by the version already embedded in the server's build metadata, or
- Extending the existing
apiVersions() gateway RPC response with an optional human-readable version field, alongside the existing protocol min/max numbers.
Either shape would let clients read the version they're talking to without guessing from behavior.
Anything else?
No response
Willingness to contribute
Search before asking
Motivation
There's currently no way to retrieve a human-readable Fluss version string from a running cluster via the client API.
apiVersions()is a gateway-level RPC (not onAdmin) and returns only protocolapi_key/min/maxnumbers plusserver_type— no semantic version like0.9.0or0.10.1.Any tool built on top of Fluss (a CLI, a UI, a monitoring agent) that wants to display which Fluss version a cluster is running — or that needs to adapt its own behavior to what a given server version actually supports (for example, the alterable table-property allow-list in
FlussConfigUtils.isAlterableTableOptiondiffers across versions) — currently has no way to query this from the server itself; it has to be supplied out-of-band by whoever operates the cluster.Solution
Add a way to retrieve the running server's version string, for example:
Adminmethod, e.g.CompletableFuture<String> getClusterVersion(), backed by the version already embedded in the server's build metadata, orapiVersions()gateway RPC response with an optional human-readable version field, alongside the existing protocol min/max numbers.Either shape would let clients read the version they're talking to without guessing from behavior.
Anything else?
No response
Willingness to contribute