Hi all, KIP-853 is shipping in 3.9. If we have to delay 3.9 to accomplish this, we will, but that seems very unlikely at this point. We are mostly on schedule so far.
Trunk is 4.0. best, Colin On Tue, Jul 30, 2024, at 15:35, Greg Harris wrote: > Hi Matthias, > > I agree with you. > >> The only assumption on my side was, that we are actually pretty sure >> that we will hit case (1) or (2)... > > I want this to be the case, but we were pretty sure that KIP-853 was going > to be in 3.8 up until it wasn't ready. I believe we need to plan for the > worst case, while being flexible to implement case (1) or (2) if the > conditions are met. > >> we should not have a 3.9 release branch, and trunk should stay on >> 3.9-SNAPSHOT for the time being... > > I agree. I think that selectively enforcing the current feature freeze > deadline for other KIPs but not KIP-853 may unnecessarily delay those other > KIPs 3-4 months. > Our time-based release schedule's primary goal is to get features out in a > timely manner, and it looks like this feature freeze could prevent that. > > In that case, a straightforward revert would be the way forward: > https://github.com/apache/kafka/pull/16737 > > Thanks, > Greg > > On Tue, Jul 30, 2024 at 3:22 PM Matthias J. Sax <mj...@apache.org> wrote: > >> Thanks Greg. Overall, this makes sense to me. >> >> The only assumption on my side was, that we are actually pretty sure >> that we will hit case (1) or (2)... >> >> And I actually also thought, that completing the required KRaft work >> would only take a few more weeks, and that is also why we have a 3.9 >> release branch already... >> >> If there is so much uncertainty about finishing KRaft work, why did we >> cut a 3.9 branch now, and have a dedicate release plan for it? Colin did >> propose the release plan with the goal in mind to quickly do a release >> after 3.8, which would contain the missing KRaft things. >> >> If we might only release 3.9 in October/November, the current release >> plan with kip/feature/code freeze deadlines does not make sense to me, >> and we should not have a 3.9 release branch, and trunk should stay on >> 3.9-SNAPSHOT for the time being... >> >> >> -Matthias >> >> On 7/30/24 3:03 PM, Greg Harris wrote: >> > Hi all, >> > >> > I'd like to clarify my understanding of the path forward, the one I voted >> > for in KIP-1012 and what I understood to be the consensus in the 3.8.0 >> > release thread. >> > >> > 1. If KIP-853 is feature-complete before October, Kafka 3.9 can be >> released >> > ASAP with KIP-853. There will be no 3.10 release, and 4.0 will follow 4 >> > months after 3.9, no later than February. >> > 2. If KIP-853 is feature complete in October, Kafka 3.9 should be >> released >> > in October as a normal release, with KIP-853. There will be no 3.10 >> > release, and 4.0 will follow 4 months after 3.9, in February. >> > 3. If KIP-853 is not feature complete in October, Kafka 3.9 should be >> > released in October as a normal release, without KIP-853. There will be a >> > 3.10 release that may or may not contain KIP-853 no later than February. >> > >> > As we are not sure which path will be taken, the most conservative >> strategy >> > is to bump to 3.10, and only after we know we're in case 1 or 2, bump the >> > version to 4.0 and skip 3.10. >> > If we leave the version bump to 4.0 in place, and later discover that we >> > are in case 3, it will be very damaging for the project, causing either a >> > big release delay, confusion for users, or unaddressed bugs. >> > >> > Thanks, >> > Greg >> > >> > On Tue, Jul 30, 2024 at 2:14 PM Igor Soarez <i...@soarez.me> wrote: >> > >> >> My understanding was that the reason for the shorter cycle >> >> to the 3.9 release was based on the assumption that KIP-1012 >> >> would be ready soon, so we could get to 4.0 quicker. >> >> >> >> If we can't move to 4.0 sooner, what's to gain with an early 3.9? >> >> >> >> -- >> >> Igor >> >> >> > >>
