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 > >> > > >
