IMO a bridge release, or one that you have to upgrade to before upgrading to the breaking release should be numbered as the last of the 2.x series...
In other words, it's acceptable to say "before upgrading to 3.0, first upgrade to 2.9" but it's very unexpected to say "before upgrading to 3.1, first upgrade to 3.0"... no one will be expecting that. On Tue, May 5, 2020 at 12:37 PM Ryanne Dolan <ryannedo...@gmail.com> wrote: > > 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? > > Exactly. Why would 3.1 be the breaking release? No one would expect > everything to break going from 3.0 to 3.1 > > 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 > > > -- *Jeff Widman* jeffwidman.com <http://www.jeffwidman.com/> | 740-WIDMAN-J (943-6265) <><
