On Tue, Jul 30, 2024, at 15:22, Matthias J. Sax 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... >
Hi Matthias, There is no uncertainty. We have been working hard on KIP-853 and there are only 3 or 4 PRs left to go before feature completeness. Please let's not create confusion (I realize, unintentionally) best, Colin > > -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 >>> >>
