Hi everyone,

I'm cancelling the vote for Apache Fluss 1.0.0 RC1 due to the
following issues identified during release verification and testing:

(1) C++ Bazel build: building the C++ client from the source
distribution fails because type_lowering.hpp is missing from the
declared build inputs.
https://github.com/apache/fluss/issues/4376
Fixed in: https://github.com/apache/fluss/pull/4387

(2) Stale KV files: a former leader restarting as a follower can
retain unused local KV directories, even after the table is dropped,
causing disk space to accumulate.
https://github.com/apache/fluss/issues/4400
Fixed in: https://github.com/apache/fluss/pull/4407

(3) License and notice packaging: missing third-party license texts,
incorrect dependency license declarations, and incomplete notices were
found across the source distribution, Java plugins, Gateway binaries,
and Python wheels.
Fixed in: https://github.com/apache/fluss/pull/4398

The fixes have been merged into release-1.0. We will prepare RC2 and
start a new vote.

Thank you to everyone who tested RC1, shared feedback, and contributed
fixes. Apologies for the extra verification round.

Best,
Jark

On Thu, 17 Sept 2026 at 22:33, Lorenzo Affetti via dev
<[email protected]> wrote:
>
> +1 non-binding
>
> Hi all,
>
> We ran our internal release-validation pipeline against the release-1.0
> branch (commit 5dde65c,
> 15 Sep) and wanted to share what we covered and what we saw.
>
> Setup under test
> ----------------
> A Fluss distribution built from release-1.0, deployed on Kubernetes: a
> 3-node ZooKeeper ensemble,
> one CoordinatorServer, three TabletServers, remote storage on S3. Clients
> authenticate over
> SASL/PLAIN. Workloads run as independent Flink 1.20 SQL jobs and as
> standalone Java client jobs.
>
> What we exercised
> -----------------
> - Log tables: streaming append of generated rows, then a batch re-read from
> the earliest offset,
>   so tiered remote log segments are fetched rather than served from local
> disk.
> - Primary-key tables: streaming upsert writes followed by a snapshot read.
> - Java client: a full create / write / read / drop cycle against both log
> and PK tables.
> - Lake tiering to Iceberg (Hadoop catalog): the tiering service running
> continuously alongside
>   streaming writers into datalake-enabled log and PK tables at 1s
> freshness, then batch reads of
>   the corresponding $lake tables, asserting row counts. Union reads across
> hot and lake data are
>   outside this pass, since PK union read on Iceberg is still open
> (apache/fluss#3048).
> - Lookup joins: a seeded dimension table probed by a Flink temporal join in
> both async and sync
>   lookup modes, with probe keys split 50/50 between guaranteed hits and
> guaranteed misses.
> - Cluster health after every suite, from the server metrics: remote log
> segments produced, KV
>   snapshots produced and remote KV state present, active TabletServer count
> non-decreasing,
>   offline bucket count non-increasing, under-replicated buckets back to
> zero, no under-min-ISR
>   buckets, request error rate not trending up.
>
> Results
> -------
> All scenarios passed, and every cluster-health assertion held across the
> run.
>
> Happy to re-run specific scenarios if that would help the release.
>
> Best,
> Lorenzo
>
> On Wed, Sep 16, 2026 at 5:41 PM Rich Bowen <[email protected]> wrote:
>
> > +1 (non-binding)
> >
> > * Verified signatures and hashes on the following files as per
> > https://apache.org/info/verification.html
> >   - fluss-1.0.0-bin.tgz (SHA512, GPG signature)
> >   - fluss-1.0.0-src.tgz (SHA512, GPG signature)
> >   - fluss-gateway-1.0.0-bin-linux-amd64.tgz (SHA512, GPG signature)
> >   - fluss-gateway-1.0.0-bin-linux-arm64.tgz (SHA512, GPG signature)
> > * Verified LICENSE and NOTICE files
> >
>
>
> --
> Lorenzo Affetti
> Senior Software Engineer @ Flink Team
> Ververica <http://www.ververica.com>

Reply via email to