+1 for removing MM 1.0 when we cut a breaking release. It is sad to see that we are still investing in it (I just saw a KIP toward improving its reset policy).
My understanding was that KIP-590 is not breaking compatibility, I think Guozhang said that in response to my question on the discussion thread. Overall, since Kafka has time-based releases, we can make the call on 3.0 vs 2.7 when we are at "KIP freeze date" and can see which features are likely to make it. On Mon, May 4, 2020 at 5:13 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > Hey Colin, I think we should wait until after KIP-500's "bridge release" so > there is a clean break from Zookeeper after 3.0. The bridge release by > definition is an attempt to not break anything, so it theoretically doesn't > warrant a major release. If that's not the case (i.e. if a single "bridge > release" turns out to be impractical), we should consider forking 3.0 while > maintaining a line of Zookeeper-dependent Kafka in 2.x. That way 3.x can > evolve dramatically without breaking the 2.x line. In particular, anything > related to removing Zookeeper could land in pre-3.0 while every other > feature targets 2.6. > > If you are proposing 2.6 should be the "bridge release", I think this is > premature given Kafka's time-based release schedule. If the bridge features > happen to be merged before 2.6's feature freeze, then sure -- let's make > that the bridge release in retrospect. And if we get all the post-Zookeeper > features merged before 2.7, I'm onboard with naming it "3.0" instead. > > That said, we should aim to remove legacy MirrorMaker before 3.0 as well. > I'm happy to drive that additional breaking change. Maybe 2.6 can be the > "bridge" for MM2 as well. > > Ryanne > > On Mon, May 4, 2020, 5:05 PM Colin McCabe <cmcc...@apache.org> wrote: > > > Hi all, > > > > We've had a few proposals recently for incompatible changes. One of them > > is my KIP-604: Remove ZooKeeper Flags from the Administrative Tools. The > > other is Boyang's KIP-590: Redirect ZK Mutation Protocols to the > > Controller. I think it's time to start thinking about Kafka 3.0. > > Specifically, I think we should move to 3.0 after the 2.6 release. > > > > From the perspective of KIP-500, in Kafka 3.x we'd like to make running > in > > a ZooKeeper-less mode possible (but not yet the default.) This is the > > motivation behind KIP-590 and KIP-604, as well as some of the other KIPs > > we've done recently. Since it will take some time to stabilize the new > > ZooKeeper-free Kafka code, we will hide it behind an option initially. > > (We'll have a KIP describing this all in detail soon.) > > > > What does everyone think about having Kafka 3.0 come up next after 2.6? > > Are there any other things we should change in the 2.6 -> 3.0 transition? > > > > best, > > Colin > > > -- Gwen Shapira Engineering Manager | Confluent 650.450.2760 | @gwenshap Follow us: Twitter | blog
