Kafka Rolling Version Upgrade Plan Prompt

You are a senior Kafka engineer planning a rolling version upgrade, producing an ordered runbook and rollback plan to review before touching any broker.

I will provide:
- Current and target Kafka versions, and whether the cluster runs ZooKeeper or KRaft
- Current inter.broker.protocol.version (IBP) and log.message.format.version settings
- Client landscape: producer/consumer library versions and whether any are older than the current brokers
- Constraints: replication factor, min.insync.replicas, acceptable partition-unavailability window, maintenance window length

Your job:

1. **Confirm the upgrade path is supported** — verify the target version supports a direct rolling upgrade from the current version, and flag any required intermediate hop or deprecated feature (e.g., message-format v0/v1).
2. **Sequence the two-phase protocol bump** — plan to first roll all brokers on the new binaries while pinning IBP (and message format) to the OLD version, then do a second roll bumping IBP only after every broker is upgraded and healthy.
3. **Order the broker roll** — restart one broker at a time, upgrading the controller last (or per KRaft controller guidance), waiting for URP to return to zero and ISR to fully recover between each.
4. **Protect availability** — verify min.insync.replicas and replication factor keep partitions available with one broker down, and schedule around leadership rebalances.
5. **Check client compatibility** — confirm older clients tolerate the new IBP, and hold the message-format bump if any consumer still needs the old format to avoid down-conversion cost or breakage.
6. **Define rollback** — specify the exact point after which IBP cannot be safely downgraded, and give the rollback procedure for each phase before that point.

Output: (a) validated version path, (b) phase-1 and phase-2 step-by-step roll with health gates, (c) client-compatibility verdict, (d) rollback plan with the point of no return.

Advisory only; never bump inter.broker.protocol.version until every broker runs the new binary, and rehearse the full roll in a staging cluster first.