LoginSign Up
← Back to all sparks
S

Strimzi

INFRA · APIS
Velocity5.0

Kubernetes operator for running and managing Apache Kafka clusters

strimzi.io ↗

Strimzi's 1.2.0 candidate closes with a logging fix and nothing else

kafkakubernetes-operatorrelease-candidateserver-side-applyfeature-gatescrd-migration
◆Current state
The 1.2.0 release cycle has reached its second candidate, and it is a small one: a single fix for incorrect CA logging on top of rc1. Everything substantive in this release landed in rc1 — Kafka 4.3.1 support, per-pod volume templates, and server-side apply now permanently enabled. This feed publishes only release candidates and never the finals, so an rc is the record of what shipped.
◆Where it's heading
Post-1.0 Strimzi is spending its cycles on how the operator manages Kubernetes resources rather than on new Kafka surface. ServerSideApplyPhase1 has gone alpha to GA and is now always on, and 1.2.0 changes install-time defaults toward Restricted Pod Security Standard security contexts and volume-mounted Service Account tokens. A second candidate carrying one logging fix says the cycle is converging rather than still absorbing change — the CRD v1-only requirement from 1.0.0 remains the loudest thing in every release body.
◆Prediction
Expect 1.2.0 final shortly with no further candidates, and the next cycle to advance one of the open feature gates — UseBackgroundPodDeletion is the likeliest to move from alpha to beta.

◆Recent moves

  1. 13h ago

    1.2.0 RC2 lands one CA logging fix

    The second 1.2.0 candidate carries a single change — incorrect CA logging — against rc1's Kafka 4.3.1 support and per-pod volume templates. The container image table is the bulk of the body. A one-fix candidate three days after the first is the sign of a cycle closing, not of new work arriving.

    View source ↗
  2. 3d ago

    Kafka 4.3.1, per-pod volume templates, server-side apply GA

    The 1.2.0 candidate continues the post-1.0 pattern of tracking Apache Kafka releases while tightening operator defaults: Kafka 4.3.1 support, per-pod templated additional volumes, Maven mirror configuration for Connect builds, and broker cordoning during scale-down auto-rebalancing. The ServerSideApplyPhase1 gate reaches GA and is permanently enabled, completing a migration that was staged across earlier releases. Installation files now default to the Restricted Pod Security Standard security context and mount Service Account tokens through a volume instead of auto-mounting them.

    View source ↗
  3. 1mo ago

    Kafka 4.3.0 support; 4.1.x dropped; connector stop semantics fixed

    The 1.1.0 candidate set the cadence the 1.2.0 line follows: add the newest Kafka versions, drop the oldest, and fix connector state semantics. Its tlsroute Gateway API listener and per-broker template options are the same kind of configuration-surface widening that 1.2.0 extends with per-pod volumes.

    View source ↗
  4. 2mo ago

    1.0.1 release preparation tag

    A bare preparation tag for the 1.0.1 patch, carrying only a sign-off line and no release notes. It marks the branch point rather than any change users would see.

    View source ↗
  5. 3mo ago

    Second 1.0.0 candidate fixes connector resume

    Second candidate for 1.0.0, carrying a single fix for resuming stopped or paused Kafka Connect connectors. Connector state handling stayed a live problem through 1.1.0, which revisited the same area.

    View source ↗
  6. 4mo ago

    1.0 drops every CRD API but v1

    ⚡ SPARK

    The release that defines the current era for this operator: 1.0.0 removed every CRD API except v1, making conversion a precondition for any upgrade. Every release since — including 1.2.0 — still opens with that warning banner, which is why the feed reads as a post-migration maintenance line.

    View source ↗