Ryanne Dolan <ryannedo...@gmail.com> wrote on 05/05/2020 20:36:49: > Exactly. Why would 3.1 be the breaking release? No one would expect > everything to break going from 3.0 to 3.1
Agree completely > > Ryanne > > On Tue, May 5, 2020 at 2:34 PM Gwen Shapira <g...@confluent.io> wrote: > > > It sounds like the decision to make the next release 3.0 is a bit arbitrary > > then? > > > > With Exactly Once, we announced 1.0 as one release after the one where EOS > > shipped, when we felt it was "ready" (little did we know... but that's > > another story). > > 2.0 was breaking due to us dropping Java 7. > > > > In 3.0 it sounds like nothing is breaking and our big change won't be > > complete... so, what's the motivation for the major release? > > > > On Tue, May 5, 2020 at 12:12 PM Guozhang Wang <wangg...@gmail.com> wrote: > > > > > I think there's a confusion regarding the "bridge release" proposed in > > > KIP-500: should it be release "3.0" or be release "2.X" (i.e. the last > > > minor release before 3.0). > > > > > > My understanding is that "3.0" would be the bridge release, i.e. it would > > > not break any compatibility, but 3.1 potentially would, so an upgrade > > from > > > 2.5 to 3.1 would need to first upgrade to 3.0, and then to 3.1. For > > > clients, all broker-client compatibility are still maintained 3.1+ so > > that > > > 2.x producer / consumer clients could still talk to 3.1+ brokers, only > > > those old versioned scripts with on "--zookeeper" would not work with > > 3.1+ > > > brokers anymore since there are no zookeepers. > > > > > > > > > Guozhang > > > > > > On Mon, May 4, 2020 at 5:33 PM Gwen Shapira <g...@confluent.io> wrote: > > > > > > > +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 > > > > > > > > > > > > > -- > > > -- Guozhang > > > > > > > > > -- > > Gwen Shapira > > Engineering Manager | Confluent > > 650.450.2760 | @gwenshap > > Follow us: Twitter | blog > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
