Hi Yuxia and Keith,
Thanks for the reviews and thoughtful comments.
Yuxia:
1. On the fluss-rust/ directory name: agreed. I think the FFI-wrapper framing
strengthens the case, alongside the sibling-directory naming and avoiding
ambiguity with the existing fluss-client/ Java module.
2. On docs/clients/: agreed.
3. On release cadence: agreed. I will revise the FIP towards fully joint
X.Y.Z releases from one tag, including patch releases. That keeps the
project version simple for users and avoids separate Java/Rust/binding
version lines after consolidation.
Keith:
1. Yes and I think this is one of the concrete benefits of the merge.
Today, crates/fluss-test-cluster/test-images.env pins
apache/fluss:0.9.0-incubating, with no automation tying them to server-side
changes. After the merge, the test cluster can build the server from the
local Java sources, so a server-side regression would be caught by Rust CI
in the same PR.
Rust-side tests are currently very fast, under a minute for roughly 400
unit tests - and I think we should keep that property. After the merge, I
would avoid rebuilding the Java server for every Rust-only PR. Instead, I
think the right setup is two lanes:
- Default Rust/binding CI uses a cached server image built from main. This
keeps Rust-only and binding-only PRs fast.
- Server-compat CI runs when a PR changes fluss-server/** or
fluss-rpc/src/main/proto/**. That lane builds the server from the PR
sources and runs the Rust/binding integration tests against that build.
This gives us same-PR detection for server-side regressions without slowing
down normal Rust and binding development. This is also a standard GitHub
Actions pattern, for example, Apache Spark has a dedicated workflow for
building and caching CI Docker images. The exact registry and retention
policy can be worked out during implementation.
2. Yes, I would update the Rust and binding CI filters to include
fluss-server/** specifically:
Rust core CI:
fluss-rust/Cargo.*
OR fluss-rust/crates/**
OR fluss-rpc/src/main/proto/**
OR fluss-server/**
Binding CI:
fluss-rust/bindings/<lang>/**
OR fluss-rpc/src/main/proto/**
OR fluss-server/**
I would use fluss-server/** rather than all Java paths because fluss-flink/,
fluss-spark/, etc. do not affect Rust client tests. If CI duration becomes
a problem, we can split this into smoke coverage for Java-side changes and
full coverage for Rust-side changes. I would prefer full coverage first,
then optimize once we have real CI timing data.
3. For documentation:
- fluss-rust/website/docs/developer-guide/contributing.md can merge into
website/community/how-to-contribute/, with a Rust-specific toolchain
subsection.
- fluss-rust/website/docs/release/* can merge into
website/community/how-to-release/, alongside the existing
creating-a-fluss-release.mdx and verifying-a-fluss-release.md.
With joint versioning, as discussed above, one verification document should
cover both trees.
4. Agreed, this is a real tradeoff. My proposed mitigation is:
- Update website/community/how-to-release/verifying-a-fluss-release.md to
cover all current publish targets: Maven Central, crates.io for fluss-rs,
and PyPI for pyfluss.
- Note that fluss-cpp has no registry publish today; it is currently
build-from-source only via Bazel/CMake.
- Treat Elixir/hex.pm as post-1.0 roadmap unless we decide otherwise.
- Add a pre-RC checklist covering cargo publish --dry-run, TestPyPI staging
install, and a fluss-cpp Bazel build smoke test, so we catch packaging
breakage before the RC rather than during the VOTE.
The larger RC surface is real, but I think it is partially offset by removing
today’s two-repo coordination problem. For example, a server protocol fix
plus a matching Rust client fix currently requires coordinated changes and
releases across two repositories.
Side note: section 1.2 currently says that the
fluss.apache.org/docs/apis/*-client.md pages are stubs. That wording is loose:
apis/ currently has java-client.md, which is substantive, and
client-support-matrix.md, but no python/cpp/rust pages. I will reword that part.
-- Anton
ср, 29 апр. 2026 г. в 22:07, Keith Lee <[email protected]>:
>
> Thank you Anton for driving.
>
> +1 for the plan. LGTM overall.
>
> A few things I’d like to suggest:
>
> 1. Rust and binding CIs should test against current version of server (we
> currently peg to latest release IIRC).
>
> 2. Should CI path filter for Rust core be updated to include Java side
> changes? This is so that we can detect server side regression that might
> cause issue on rust/bindings side.
>
> 3. On doc restructuring, can you clarify where we are moving the
> “Contributing” and “Release” sections currently on
> https://clients.fluss.apache.org?
>
> 4. Unified release makes sense to me. I’d like to call out however that it
> is a trade off i.e. releases surface area are bigger, it’s more likely that
> go through more release candidates before releases. We will need to ensure
> that verifying release page is up to date to include rust and other
> languages bindings.
>
> Thank you for your awesome work as usual!
>
> Keith
>
> On Wed, 29 Apr 2026 at 13:23, yuxia <[email protected]> wrote:
>
> > Thanks Anton for driving it. +1 for that. LGTM overall. Few comments below:
> >
> > 1. I'm fine with fluss-rust as the directory name, Python and C++ bindings
> > are fundamentally Rust FFI wrappers (PyO3, CXX) — they belong under the
> > Rust tree by implementation reality. It also avoids semantic ambiguity with
> > the existing fluss-client/ Java module.
> >
> > 2. Docs section name: I think docs/clients/ is fine
> >
> > 3. Regarding to Release cadence: +1 for unified versioning. Too many
> > independent version numbers create confusion for users. For patch releases,
> > I'd prefer shipping them jointly as well — this keeps versions from
> > diverging and is actually simpler in practice, since after consolidation
> > we'll have a single release pipeline anyway. Cutting one tag that covers
> > everything should be less work than coordinating separate releases.
> >
> > Best regards,
> > Yuxia
> >
> > ----- 原始邮件 -----
> > 发件人: "Anton Borisov" <[email protected]>
> > 收件人: "dev" <[email protected]>
> > 发送时间: 星期六, 2026年 4 月 25日 上午 8:24:59
> > 主题: Re: [DISCUSS] FIP: Consolidate apache/fluss-rust into apache/fluss
> >
> > Hi,
> >
> > Thank you Hongshun, I really appreciate your offer to help.
> >
> > Also I created a page in Confluence:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=421957144
> >
> > - Anton
> >
> > чт, 23 апр. 2026 г. в 13:38, Hongshun Wang <[email protected]>:
> > >
> > > Hi Anton,
> > > Thank you very much for pushing this forward. I can help with it if
> > needed.
> > > +1 from my side.On Thu, Apr 23, 2026 at 3:28 PM Anton Borisov <
> > > [email protected]> wrote:
> > >
> > > Best,
> > > Hongshun
> > >
> > > > Hi Leonard,
> > > >
> > > > Thanks a lot for the support! Appreciate it
> > > >
> > > > Giannis has already granted me the Confluence permissions, so I will
> > > > migrate
> > > > this draft there.
> > > >
> > > > - Anton
> > > >
> > > > чт, 23 апр. 2026 г. в 09:14, Leonard Xu <[email protected]>:
> > > > >
> > > > > +1 from my side, the motivation and the proposed merge plan makes
> > sense
> > > > to me.
> > > > >
> > > > > Btw, could you left your jira account name? Anton, we can add the
> > > > Confluence edit permission for you.
> > > > >
> > > > > Best,
> > > > > Leonard
> > > > >
> > > > > > 2026 4月 23 14:50，Anton Borisov <[email protected]> 写道：
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Following up on the 0.2.0-incubating roadmap thread, where the repo
> > > > > > merge came through as the strongest priority signal, I am opening
> > this
> > > > > > as its own [DISCUSS] as promised.
> > > > > >
> > > > > > Per the consensus on that thread, 0.2.0 development continues on
> > > > > > fluss-rust in parallel and is not blocked by this FIP.
> > > > > >
> > > > > > I do not currently have edit rights on the FLUSS Confluence space,
> > so
> > > > > > I am posting the full draft inline. Once discussion converges, a
> > > > > > committer can paste the agreed text into a FIP-XX page. Please
> > treat
> > > > > > the text below as a working draft; I am happy to revise it as
> > feedback
> > > > > > comes in.
> > > > > >
> > > > > > ===============================================================
> > > > > > FIP-XX: Consolidate apache/fluss-rust into apache/fluss
> > > > > >
> > > > > > Discussion thread: this thread
> > > > > > Vote thread: TBD
> > > > > > Release: Fluss 1.0 (target)
> > > > > > Status: Under Discussion
> > > > > >
> > > > > > Motivation
> > > > > > =============
> > > > > >
> > > > > > Fluss source code currently lives in two ASF repos.
> > > > > >
> > > > > > 1.1 Current layout today
> > > > > >
> > > > > > apache/fluss
> > > > > > ├─ fluss-server/
> > > > > > ├─ fluss-client/
> > > > > > ├─ fluss-rpc/
> > > > > > │ └─ src/main/proto/*.proto
> > > > > > ├─ fluss-flink/, fluss-spark/, ...
> > > > > > ├─ website/
> > > > > > │ └─ fluss.apache.org
> > > > > > └─ .github/workflows/
> > > > > >
> > > > > > apache/fluss-rust
> > > > > > ├─ crates/fluss/
> > > > > > │ └─ src/proto/*.proto
> > > > > > │ hand-ported subset
> > > > > > ├─ bindings/python/
> > > > > > ├─ bindings/cpp/
> > > > > > ├─ bindings/elixir/
> > > > > > ├─ website/
> > > > > > │ └─ clients.fluss.apache.org
> > > > > > └─ .github/workflows/
> > > > > >
> > > > > > fluss-rust was incubated in its own repo so the Rust core could
> > move
> > > > > > quickly. With 1.0 GA on the horizon, the costs of the split now
> > exceed
> > > > > > the benefit.
> > > > > >
> > > > > > As discussed on the 0.2.0 thread, 1.0 should represent the complete
> > > > > > form of the project: all language SDKs and unified release
> > > > > > coordination from a single repository, to signal maturity to
> > users. A
> > > > > > fragmented multi-repo layout at GA undermines that message.
> > > > > >
> > > > > > 1.2 Concrete costs today
> > > > > >
> > > > > > Protobuf schema is duplicated and can diverge. The source of truth
> > is
> > > > > > fluss-rpc/src/main/proto/FlussApi.proto (package fluss).
> > > > > > fluss-rust carries a hand-maintained subset at
> > > > > > crates/fluss/src/proto/fluss_api.proto (package proto).
> > > > > > The subset exists only because the two repos cannot share files;
> > > > > > nothing enforces consistency.
> > > > > >
> > > > > > Server version is pinned manually in two files:
> > > > > > crates/fluss-test-cluster/test-images.env and
> > > > > > bindings/elixir/test/support/cluster.ex, both pointing today to
> > > > > > apache/fluss:0.9.0-incubating, with no automation.
> > > > > >
> > > > > > Docs are split across two subdomains. fluss.apache.org/docs/apis/
> > > > > > *-client.md pages are stubs that link out to
> > > > > > clients.fluss.apache.org/user-guide//... This means two
> > > > > > Docusaurus builds and two deployment pipelines.
> > > > > >
> > > > > > Infrastructure is duplicated: 8 CI workflows in each repo,
> > > > > > duplicated LICENSE / NOTICE / DISCLAIMER files at repo root, and
> > > > > > two release trains.
> > > > > >
> > > > > > Cross-repo changes cost two PRs, two reviews, and a Docker image
> > cut
> > > > > > per wire-protocol change.
> > > > > >
> > > > > > 1.3 ASF peer evidence
> > > > > >
> > > > > > ASF peer evidence points the other way: mature ASF projects
> > > > > > overwhelmingly colocate language bindings with core.
> > > > > >
> > > > > > Apache Thrift -> apache/thrift/lib/{java,py,cpp,rs,go,rb,...}
> > > > > >
> > > > > > Apache Avro -> apache/avro/lang/{java,py,c,rust,ruby,...}
> > > > > >
> > > > > > Apache Beam -> apache/beam/sdks/{java,python,go,typescript}
> > > > > >
> > > > > > PyFlink -> apache/flink/flink-python/
> > > > > >
> > > > > > PySpark -> apache/spark/python/
> > > > > >
> > > > > > Apache Arrow is the visible counter-example: arrow-rs, arrow-go,
> > > > > > arrow-java, and arrow-js live in separate repos. Apache Avro also
> > > > > > externalized its Go binding (apache/avro-go) on a similar
> > trajectory.
> > > > > > In both cases, the split happened after the format stabilized and
> > > > > > after the specific language community had grown large enough to
> > > > > > self-sustain.
> > > > > >
> > > > > > Fluss is at neither milestone. The wire protocol is still evolving
> > > > > > aggressively pre-1.0, and the Rust, Python, C++, and Elixir
> > bindings
> > > > > > are all co-maintained by the same contributors. Splitting now
> > incurs
> > > > > > coordination overhead that Arrow and Avro only accepted at
> > maturity,
> > > > > > without yet having their enabling conditions.
> > > > > >
> > > > > > The Flink connector-externalization retrospective is sometimes
> > cited,
> > > > > > but does not really apply: connectors are N external-system
> > > > > > integrations maintained by independent communities, not N language
> > > > > > wrappers over one wire protocol.
> > > > > >
> > > > > > Public interfaces
> > > > > > ====================
> > > > > >
> > > > > > None. Published artifacts remain unchanged:
> > > > > >
> > > > > > Maven Central: org.apache.fluss:fluss-*
> > > > > >
> > > > > > crates.io: fluss-rs
> > > > > >
> > > > > > PyPI: pyfluss
> > > > > >
> > > > > > git: Elixir fluss (planned hex.pm publication)
> > > > > >
> > > > > > CMake / Bazel: fluss-cpp
> > > > > >
> > > > > > Proposed changes
> > > > > > ===================
> > > > > >
> > > > > > Jark outlined the merge as five workstreams: code migration, CI
> > > > > > unification, documentation restructuring, issue migration, and
> > > > > > contributor workflow changes. Sections 3 and 4 address each.
> > > > > >
> > > > > > 3.1 Code migration - target layout
> > > > > >
> > > > > > apache/fluss/
> > > > > > ├─ fluss-server/ (Java, unchanged)
> > > > > > ├─ fluss-client/ (Java, unchanged)
> > > > > > ├─ fluss-rpc/ (single .proto source; see 3.4)
> > > > > > │ └─ src/main/proto/FlussApi.proto
> > > > > > ├─ fluss-flink/, fluss-spark/, ... (Java modules, unchanged)
> > > > > > ├─ fluss-rust/ (new: today's apache/fluss-rust tree)
> > > > > > │ ├─ Cargo.toml, Cargo.lock
> > > > > > │ ├─ crates/{fluss, examples, fluss-test-cluster}/
> > > > > > │ ├─ bindings/{python, cpp, elixir}/
> > > > > > │ ├─ justfile, MODULE.bazel, rust-toolchain.toml,
> > > > > > │ │ deny.toml, rustfmt.toml
> > > > > > │ └─ scripts/
> > > > > > ├─ website/ (unified Docusaurus; see 3.3)
> > > > > > └─ .github/workflows/ (unified with path filters; see 3.2)
> > > > > >
> > > > > > fluss-rust mirrors sibling naming such as fluss-server/ and
> > > > > > fluss-flink/. Bindings stay nested because they share a Cargo
> > > > > > workspace, rust-toolchain.toml, deny.toml, and workspace-level
> > > > > > dependency resolution with the Rust core.
> > > > > >
> > > > > > 3.2 CI unification
> > > > > >
> > > > > > A single .github/workflows/ directory. Path filters are a hard
> > > > > > requirement:
> > > > > >
> > > > > > Java CI: pom.xml, fluss-*/** (excluding fluss-rust/), tools/**
> > > > > >
> > > > > > Rust core CI: fluss-rust/Cargo.*, fluss-rust/crates/**
> > > > > > OR fluss-rpc/src/main/proto/**
> > > > > >
> > > > > > Binding CI: fluss-rust/bindings//**
> > > > > > OR fluss-rpc/src/main/proto/**
> > > > > >
> > > > > > Docs build: website/**
> > > > > >
> > > > > > Existing release workflows move over unchanged. Their triggers are
> > > > > > tag-based and already disjoint from each other.
> > > > > >
> > > > > > 3.3 Documentation restructuring
> > > > > >
> > > > > > fluss/website/docs/
> > > > > > ├─ intro.md
> > > > > > ├─ quickstart/
> > > > > > ├─ concepts/
> > > > > > ├─ clients/ (new section)
> > > > > > │ ├─ support-matrix.md
> > > > > > │ ├─ java/
> > > > > > │ ├─ rust/
> > > > > > │ ├─ python/
> > > > > > │ └─ cpp/
> > > > > > ├─ engine-flink/, engine-spark/, ...
> > > > > > └─ ...
> > > > > >
> > > > > > clients.fluss.apache.org is retired. Redirects from old paths use
> > > > > > @docusaurus/plugin-client-redirects, with mappings generated by
> > > > > > walking the two sidebars.ts files. The
> > > > > > fluss-rust/.github/workflows/deploy_documentation.yml workflow is
> > > > > > removed; deployment converges on the existing fluss/website ->
> > > > > > apache/fluss-website dispatch.
> > > > > >
> > > > > > 3.4 Protobuf single source of truth
> > > > > >
> > > > > > Today, crates/fluss/src/proto/fluss_api.proto exists as a
> > > > > > hand-maintained subset of the Java-side canonical proto solely
> > because
> > > > > > the two repos could not share files. The merge removes that
> > > > > > constraint, and this FIP removes the subset.
> > > > > >
> > > > > > After the structural merge:
> > > > > >
> > > > > > Delete fluss-rust/crates/fluss/src/proto/fluss_api.proto.
> > > > > >
> > > > > > Point fluss-rust/crates/fluss/build.rs at the canonical proto:
> > > > > >
> > > > > > config.compile_protos(
> > > > > > &["../../../fluss-rpc/src/main/proto/FlussApi.proto"],
> > > > > > &["../../../fluss-rpc/src/main/proto"],
> > > > > > )?;
> > > > > >
> > > > > > Update the .bytes() prefixes in build.rs from ".proto." to
> > > > > > ".fluss." because the canonical proto declares package fluss.
> > > > > >
> > > > > > Update lib.rs include! from "/proto.rs" to "/fluss.rs", since
> > > > > > prost names the generated file after the proto package.
> > > > > >
> > > > > > The vendored copy exists only to satisfy crates.io packaging
> > rules;
> > > > > > the monorepo build reads the canonical proto directly. For
> > crates.io
> > > > > > publishing, vendor the canonical .proto into the crate at
> > > > > > cargo-publish time via scripts/release.sh, with build.rs falling
> > > > > > back to the in-crate copy when the monorepo path is absent.
> > > > > >
> > > > > > All existing crate::proto::TypeName call sites compile unchanged,
> > > > > > because the pub mod proto { ... } wrapper in lib.rs preserves the
> > > > > > import path.
> > > > > >
> > > > > > After this, adopting a new server RPC becomes a single-PR change:
> > the
> > > > > > message lands in the canonical proto and Rust types appear
> > > > > > automatically. Nothing remains to drift against, so no CI
> > drift-gate
> > > > > > is needed. Section 6 covers why a drift-gate alone would be the
> > wrong
> > > > > > answer.
> > > > > >
> > > > > > 3.5 Release cadence
> > > > > >
> > > > > > Java server and Rust client keep their current independent SemVer
> > > > > > cadences until 1.0 GA. From 1.0 onward, both trees cut a jointly
> > > > > > numbered X.Y.Z release from a single tag; patch releases can still
> > > > > > ship independently where scope is binding-only or server-only.
> > > > > > Binding-specific SemVer continues where public APIs diverge, for
> > > > > > example if a pyfluss major bump is driven by PyO3 ABI changes.
> > > > > >
> > > > > > Open to revision: the post-1.0 release model is listed in section 8
> > > > > > and likely deserves its own [DISCUSS] once this FIP lands.
> > > > > >
> > > > > > Compatibility, deprecation, and migration plan
> > > > > > =================================================
> > > > > >
> > > > > > 4.1 Phases
> > > > > >
> > > > > > [0 Agreement] -> [1 Dry run] -> [2 Merge window] -> [3 Archive] ->
> > [4
> > > > Cleanup]
> > > > > >
> > > > > > DISCUSS + VOTE
> > > > > >
> > > > > > fork dry run
> > > > > >
> > > > > > follow-up PRs
> > > > > >
> > > > > > redirects
> > > > > >
> > > > > > INFRA ticket
> > > > > >
> > > > > > Agreement. This FIP's DISCUSS + VOTE. INFRA ticket filed and
> > > > > > resolved before VOTE is called, so the migration plan is confirmed
> > > > > > viable rather than assumed.
> > > > > >
> > > > > > Dry run on a fork: verify CI, path filters, docs build, redirects,
> > > > > > and git log --follow across the boundary.
> > > > > >
> > > > > > Merge window. Short freeze on apache/fluss-rust; structural merge
> > > > > > commit into apache/fluss. Protobuf (3.4) and docs (3.3)
> > > > > > consolidation land as separate follow-up PRs for reviewability.
> > > > > >
> > > > > > Archive. INFRA archives apache/fluss-rust read-only; issues, PRs,
> > > > > > commits, and tags remain as permalinks. Subdomain redirects go
> > > > > > live. A pinned README on the archived repo points to apache/fluss,
> > > > > > since GitHub does not forward content-moves between repos
> > > > > > automatically.
> > > > > >
> > > > > > Cleanup. Consolidate root-level duplicates such as LICENSE /
> > > > > > NOTICE / DISCLAIMER and contributor docs.
> > > > > >
> > > > > > 4.2 History preservation
> > > > > >
> > > > > > On a clone of apache/fluss-rust:
> > > > > >
> > > > > > git filter-repo --to-subdirectory-filter fluss-rust
> > > > > >
> > > > > > In apache/fluss:
> > > > > >
> > > > > > git remote add rust ../fluss-rust-rewritten
> > > > > > git fetch rust
> > > > > > git merge --allow-unrelated-histories --no-ff rust/main
> > > > > >
> > > > > > This preserves git log --follow and git blame --follow on every
> > > > > > rewritten file. git subtree breaks log --follow on files inside the
> > > > > > subtree; git filter-branch is deprecated.
> > > > > >
> > > > > > 4.3 Issue migration
> > > > > >
> > > > > > Closed issues and PRs remain at their apache/fluss-rust archive
> > URLs
> > > > > > as permalinks. Open issues at merge time are re-filed in
> > apache/fluss
> > > > > > with cross-links, scripted via gh CLI. Open PRs are reopened by
> > their
> > > > > > authors against the new path; GitHub does not support cross-repo PR
> > > > > > transfer.
> > > > > >
> > > > > > 4.4 Contributor workflow
> > > > > >
> > > > > > Contributors re-clone and re-open in-flight PRs against the new
> > path.
> > > > > > Downstream artifact consumers see no change. Docs visitors follow
> > > > > > redirects.
> > > > > >
> > > > > > 4.5 Timeline
> > > > > >
> > > > > > There is no dependency on a specific release. Target completion is
> > > > > > before 1.0 GA, per the fluss-rust roadmap 0.2.0 DISCUSS consensus.
> > > > > > Within that bound, the community can pick the window that minimizes
> > > > > > rebase pain, most likely after 0.2.0-incubating is cut, to avoid
> > > > > > forcing in-flight roadmap work to rebase across the merge.
> > > > > >
> > > > > > Test plan
> > > > > > ============
> > > > > >
> > > > > > In the merged repo, CI runs the full Java + Rust + all-binding
> > > > > > matrices on every PR.
> > > > > >
> > > > > > Path-filter correctness is explicitly tested: a Rust-only PR must
> > > > > > not trigger Java jobs, and vice versa.
> > > > > >
> > > > > > Protobuf: a change to fluss-rpc/src/main/proto/FlussApi.proto alone
> > > > > > produces a green Rust build with no Rust-side edit, confirming the
> > > > > > single-source claim.
> > > > > >
> > > > > > Docs: every fluss-rust/website/docs/user-guide/... page renders
> > > > > > under fluss.apache.org/docs/clients/...; sampled old URLs
> > redirect.
> > > > > >
> > > > > > History: git log --follow on a sample migrated file shows full
> > > > > > pre-merge history.
> > > > > >
> > > > > > Rejected alternatives
> > > > > > ========================
> > > > > >
> > > > > > Status quo. The section 1 costs recur every release cycle and grow
> > > > > > with each new binding.
> > > > > >
> > > > > > Drift-gate instead of full proto consolidation. Keep the Rust
> > > > > > subset and add CI to flag divergence on messages present in both
> > > > > > files. Rejected because it catches only half the drift problem,
> > > > > > preserves a hand-maintained file whose only reason to exist was the
> > > > > > cross-repo constraint the merge removes, and adds custom comparison
> > > > > > logic to maintain.
> > > > > >
> > > > > > Polyglot-repo federation, Iceberg-style. This works for Iceberg
> > > > > > because bindings have independent maintainer communities and the
> > > > > > table-format spec is stable enough that protocol-evolution coupling
> > > > > > is low. Neither holds for Fluss pre-1.0: bindings are co-maintained
> > > > > > by the same team, and the wire protocol is still evolving
> > > > > > aggressively. For Fluss in the run-up to 1.0, locking bindings to
> > > > > > server evolution is a feature, not a bug.
> > > > > >
> > > > > > Apache Arrow precedent (arrow-rs split, 2021).
> > > > > > https://arrow.apache.org/blog/2021/05/04/rust-dev-workflow/
> > > > > > Section 1 covers the structural frame: Arrow split after
> > > > > > stabilization and after each binding had grown an autonomous
> > > > > > community. Arrow's specific 2021 rationale also inverts for Fluss.
> > > > > >
> > > > > > Git submodules. Standard UX problems and does not solve the docs
> > > > > > split.
> > > > > >
> > > > > > Further splitting into per-binding repos. This multiplies every
> > cost
> > > > > > listed in section 1.
> > > > > >
> > > > > > Flatten bindings to the top level of the merged repo. This breaks
> > > > > > the shared Cargo workspace. Keeping them under fluss-rust/
> > > > > > preserves it; rearrangement remains an option later.
> > > > > >
> > > > > > Risks
> > > > > > ========
> > > > > >
> > > > > > CI blast radius if path filters are misconfigured. Mitigated by
> > > > > > sections 3.2 and 5.
> > > > > >
> > > > > > In-flight PRs stall during the freeze. Mitigated by maintainers
> > > > > > proactively reopening high-value PRs.
> > > > > >
> > > > > > Open questions
> > > > > > =================
> > > > > >
> > > > > > Directory name for the Rust tree. Proposal: fluss-rust/
> > > > > > (mirrors fluss-server/ and fluss-flink/ sibling naming).
> > > > > > Alternatives: rust/, clients/rust/.
> > > > > >
> > > > > > Docs section name. Proposal: docs/clients/ to unify client and
> > > > > > binding docs under one heading, while keeping docs/engine-*/ for
> > > > > > pipeline integrations. Alternative: keep docs/apis/ to reduce link
> > > > > > churn during migration.
> > > > > >
> > > > > > Post-1.0 release model. Section 3.5 proposes synchronized X.Y.Z
> > > > > > across Java and Rust with independent patches. Alternative:
> > > > > > Arrow-style coordinated-but-independent versioning. This likely
> > > > > > deserves its own [DISCUSS] once this FIP lands.
> > > > > >
> > > > > > Looking forward to feedback.
> > > > > >
> > > > > > Best,
> > > > > > Anton
> > > > >
> > > >
> >
