Hi Chris, Based on some of the offline discussions we had, people generally feel that major/minor releases have a large enough overhead that they don't want them more frequently than every 4 months. (Obviously dot releases are a different story) So Josep and I didn't want to raise the issue here.
I also feel that 4 months should be enough (for anyone? :) ) But I'm always an optimist. best, Colin On Mon, Jan 8, 2024, at 13:03, Chris Egerton wrote: > Hi Colin, > > The idea isn't to hold up 4.0.0 any longer; in fact, it's the opposite. If > things slip a bit with 3.8.0 and we take, for example, an extra month to > deliver it (or even to cut the branch), I don't think this should > necessarily translate to an extra month of latency between now and 4.0.0, > given exactly what you mention about the major changes we plan to include > in 4.0.0 (which consist more of dropping support for existing things than > adding support for new things). > > If we want to avoid confusion, we could say something like "no later than 3 > to 4 months after the 3.8 branch is created". Frankly though, I think it's > unnecessary to specify an exact timeline for 4.0 in this KIP, since nothing > in the proposal actually diverges from the usual time-based release plan we > follow. The only necessary part seems to be to state that 4.0 will directly > follow 3.8 (as opposed to 3.9, 3.10, etc.). But perhaps I'm missing > something? > > Cheers, > > Chris > > On Mon, Jan 8, 2024 at 2:38 PM Colin McCabe <cmcc...@apache.org> wrote: > >> On Mon, Jan 8, 2024, at 09:05, Chris Egerton wrote: >> > Hi Josep, >> > >> > Thanks for the KIP! +1 (binding). >> > >> > One small nit: I don't think we necessarily have to hold ourselves to >> > releasing 4.0.0 "3 to 4 months after 3.8 branch is created" (quoting the >> > timeline section of the KIP). IMO it's fine to leave some wiggle room for >> > the 4.0.0 release without codifying a timeline in this KIP. Maybe >> something >> > like "some time after 3.8 branch is created" would be sufficient? >> Anyways, >> > not a huge thing, I'm sure we'll all give 4.0.0 the flexibility it needs >> > with the understanding that this KIP is more focused on 3.8.0 than 4.0.0. >> > >> >> Hmm... I don't see any obstacles in the path of releasing 4.0 after the >> traditional 4 months of development. Keep in mind, we're removing things >> from the code (the ability to support JDK8, ZooKeeper mode, etc.), not >> adding things. We already support JDK11 so saying that it's the minimum is >> a very quick change. Similarly, we already support KRaft so saying that >> it's the only mode should be a pretty quick change. >> >> Also, we added a note that "the timeline is very rough" to KIP-833 and it >> caued all kinds of confusion. So overall I'd prefer to leave the language >> about 4.0 unchanged. >> >> best, >> Colin >> >> > >> > Cheers, >> > >> > Chris >> > >> > On Mon, Jan 8, 2024 at 11:41 AM Greg Harris <greg.har...@aiven.io.invalid >> > >> > wrote: >> > >> >> Thanks Josep for leading the KIP and building consensus on 3.8! >> >> >> >> +1 (binding) >> >> >> >> Greg >> >> >> >> On Sun, Jan 7, 2024 at 11:45 PM Josep Prat <josep.p...@aiven.io.invalid >> > >> >> wrote: >> >> > >> >> > Hi all, >> >> > >> >> > Thanks for your comments, >> >> > I reworded some parts of the KIP to express that: >> >> > - The KIP is to agree that we need at least one more minor version in >> the >> >> > 3.x series >> >> > - Explicitly saying that the list of KIPs is not exhaustive and that >> if >> >> > some are not done, we would need another minor version >> >> > - Which are the KIPs/Features the community identified that should be >> >> > present in a 3.x version so they can safely migrate to a potential 4.0 >> >> > version >> >> > - The timeline of 4.0 (starting after branching, not after release) >> >> > - Wording is now focusing more on the need to have at least another >> minor >> >> > release in 3.x to enable and ease migration to a potential 4.0 version >> >> > >> >> > I always mention potential in terms of 4.0 as we don't know what will >> be >> >> in >> >> > there yet, and this KIP's scope is not meant to define this. >> >> > >> >> > Best, >> >> > >> >> > On Fri, Jan 5, 2024 at 10:46 PM Ismael Juma <m...@ismaeljuma.com> >> wrote: >> >> > >> >> > > I agree with Colin. Also, 4.0 would be started after 3.8 is branched >> >> (not >> >> > > after 3.8.0 is released). The rest looks good. >> >> > > >> >> > > Thanks! >> >> > > >> >> > > Ismael >> >> > > >> >> > > On Fri, Jan 5, 2024 at 11:27 PM Colin McCabe <cmcc...@apache.org> >> >> wrote: >> >> > > >> >> > > > Hi, >> >> > > > >> >> > > > Thanks for calling the vote, Josep. >> >> > > > >> >> > > > I re-checked this, and saw something that we missed updating. One >> >> thing >> >> > > we >> >> > > > talked about earlier is that KIP-966 is actually not required for >> >> 3.8. >> >> > > What >> >> > > > is required is some way of enabling unclean leader election by >> >> default in >> >> > > > KRaft. (Which could be KIP-966, or something else). Please revise >> >> this. >> >> > > > >> >> > > > best, >> >> > > > Colin >> >> > > > >> >> > > > On Fri, Jan 5, 2024, at 02:50, Anton Agestam wrote: >> >> > > > > +1 from me. >> >> > > > > >> >> > > > > Den fre 5 jan. 2024 kl 10:33 skrev Josep Prat >> >> > > > <josep.p...@aiven.io.invalid>: >> >> > > > > >> >> > > > >> Hi all, >> >> > > > >> >> >> > > > >> I'd like to start a vote on KIP-1012: >> >> > > > >> >> >> > > > >> >> >> > > > >> >> > > >> >> >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1012%3A+The+need+for+a+Kafka+3.8.x+release >> >> > > > >> >> >> > > > >> Discussion thread is here: >> >> > > > >> >> https://lists.apache.org/thread/kvdp2gmq5gd9txkvxh5vk3z2n55b04s5 >> >> > > > >> >> >> > > > >> Thanks! >> >> > > > >> >> >> > > > >> --- >> >> > > > >> Josep Prat >> >> > > > >> Open Source Engineering Director, aivenjosep.p...@aiven.io | >> >> > > > >> +491715557497 | aiven.io >> >> > > > >> Aiven Deutschland GmbH >> >> > > > >> Alexanderufer 3-7, 10117 Berlin >> >> > > > >> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> >> > > > >> Amtsgericht Charlottenburg, HRB 209739 B >> >> > > > >> >> >> > > > >> >> > > >> >> > >> >> > >> >> > -- >> >> > [image: Aiven] <https://www.aiven.io> >> >> > >> >> > *Josep Prat* >> >> > Open Source Engineering Director, *Aiven* >> >> > josep.p...@aiven.io | +491715557497 >> >> > aiven.io <https://www.aiven.io> | < >> >> https://www.facebook.com/aivencloud> >> >> > <https://www.linkedin.com/company/aiven/> < >> >> https://twitter.com/aiven_io> >> >> > *Aiven Deutschland GmbH* >> >> > Alexanderufer 3-7, 10117 Berlin >> >> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen >> >> > Amtsgericht Charlottenburg, HRB 209739 B >> >> >>
