One more blocker (memory leak) for 3.7:
https://issues.apache.org/jira/browse/KAFKA-16086
-Matthias
On 1/4/24 9:53 PM, Stanislav Kozlovski wrote:
Thanks Apoorv, I was going to update the mailing thread as well.
Major kudos to Apoorv for the thorough work debugging and getting to the
bottom of this tricky publishing issue, a subtle regression from the work
he did in making the kafka-clients jar shadowed.
On Thu, Jan 4, 2024 at 5:09 PM Apoorv Mittal <apoorvmitta...@gmail.com>
wrote:
Hi Stan,
I have opened the minor PR: https://github.com/apache/kafka/pull/15127 to
fix publishing the dependency. Once discussed and merged in trunk, I'll
update the 3.7 branch as well.
Regards,
Apoorv Mittal
+44 7721681581
On Thu, Jan 4, 2024 at 12:49 PM Matthias J. Sax <mj...@apache.org> wrote:
We found a blocker for 3.7:
https://issues.apache.org/jira/browse/KAFKA-16077
Already having a PR under review to fix it.
-Matthias
On 1/3/24 10:43 AM, Stanislav Kozlovski wrote:
Hey all, happy new year.
Thanks for the heads up Almog. Makes sense.
To give an update - I haven't been able to resolve the gradlewAll
publish
failure, and as such haven't been able to release an RC.
As a minor barrier, I have to also update the year in the NOTICE file,
otherwise the release script won't let me continue -
https://github.com/apache/kafka/pull/15111
Me and Apoorv synced offline and ran a few tests to debug the issue
regarding the clients build. I successfully executed `publish` when
pointing toward a custom jfrog repo with both JDK 8 and 17. Inspecting
the
debug logs, the task that previously failed
`:clients:publishMavenJavaPublicationToMavenRepository'` passed
successfully. Here's a sample of the logs -
https://gist.github.com/stanislavkozlovski/841060cb467ec1d179cc9f293c8702e7
Having read the release.py script a few times, I am not able to see
what
is
different in the setup there. It simply clones the repo anew, gets the
3.7
branch and runs the same command.
At this point, I am contemplating pushing a commit to 3.7 that modifies
the
release.py file that enables debug on the command:
diff --git a/release.py b/release.py
index 43c5809861..e299e10e74 100755
--- a/release.py
+++ b/release.py
@@ -675,7 +675,7 @@ with
open(os.path.expanduser("~/.gradle/gradle.properties")) as f:
contents = f.read()
if not user_ok("Going to build and upload mvn artifacts based on
these
settings:\n" + contents + '\nOK (y/n)?: '):
fail("Retry again later")
-cmd("Building and uploading archives", "./gradlewAll publish",
cwd=kafka_dir, env=jdk8_env, shell=True)
+cmd("Building and uploading archives", "./gradlewAll publish --debug",
cwd=kafka_dir, env=jdk8_env, shell=True)
cmd("Building and uploading archives", "mvn deploy -Pgpg-signing",
cwd=streams_quickstart_dir, env=jdk8_env, shell=True)
release_notification_props = { 'release_version': release_version,
(END)
and continuing to debug through that.
Since the release.py script grabs a new copy of origin, we have to
modify
upstream. An alternative is for me to use my local github Kafka repo,
but
that may result in the script pushing a build of that into the remote
servers.
On Tue, Jan 2, 2024 at 8:17 PM Almog Gavra <almog.ga...@gmail.com>
wrote:
Hello Stan,
I wanted to give you a heads up that
https://github.com/apache/kafka/pull/15073 (
https://issues.apache.org/jira/browse/KAFKA-16046) was identified as
a
blocker regression and should be merged to trunk by EOD.
Cheers,
Almog
On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozlovski
<stanis...@confluent.io.invalid> wrote:
Hi Apoorv,
Thanks for taking ownership and looking into this! One more caveat is
that
I believe this first publish is ran with JDK 8, as the release.py
runs
with
both JDK 8 and (if I recall correctly) 17 versions. This seems to
fail
on
the first one - so JDK 8.
Not sure if that is related in any way. And I'm also not sure if it
should
be kafka-clients or just clients.
On Sat, Dec 30, 2023 at 10:48 AM Apoorv Mittal <
apoorvmitta...@gmail.com
wrote:
Hi Stan,
Thanks for looking into the release. I worked with `./gradlewAll
publishToMavenLocal` which generates the respective
`kafka-clients.jar`
and deploys to maven local, I believed that `./gradlewAll publish`
should
just publish the artifacts to remote repository and hence should
always
work as jars successfully gets deployed to local maven.
Though now I set up the remote private maven repository for myself
(on
jfrog) and tried `./gradlewAll publish` on the 3.7 branch and
successfully completed the build with all artifacts uploaded to the
remote
repository. What seems strange to me is the error you mentioned in
the
previous email regarding the reference of the clients jar. I suppose
the
reference should be to `kafka-clients.jar` rather than
`clients.jar`,
I
might be missing if something else gets triggered in the release
pipeline.
Do you think I should set up the remote repository as per the
instructions
in `release.py` and try running `./release.py` as that might do
something
different, though I suspect that it should?
[image: Screenshot 2023-12-30 at 9.33.42 AM.png]
Regards,
Apoorv Mittal
On Fri, Dec 29, 2023 at 2:13 AM Colin McCabe <cmcc...@apache.org>
wrote:
Just to update this thread, everything in KAFKA-14127 is done now.
A
few
tasks got moved to a separate umbrella JIRA.
Some folks are going to do more testing, both manual and automated,
in
the next week or two. I think this will give us a good indicator of
stability and what we need to fix.
Right now I'm leaning towards just making it GA since that's how
most
features work. It's kind of rare for us to do a multi-step rollout
for
new
features.
best,
Colin
On Wed, Dec 20, 2023, at 03:43, Mickael Maison wrote:
Hi,
With the current timeline for 3.7, I tend to agree with Viktor
that
JBOD support in KRaft is unlikely to receive the extensive testing
this feature needs before releasing. And that's not counting the
testing tasks left to do in
https://issues.apache.org/jira/browse/KAFKA-14127.
I'm fine sticking to the current 3.7 timeline but I'd err on the
safe
side and mark JBOD as early access to avoid major issues. Kafka is
known for its robustness and resiliency and we certainly don't
want
to
lose the trust we gained over years.
Thanks,
Mickael
On Wed, Dec 20, 2023 at 12:24 AM Ismael Juma <m...@ismaeljuma.com>
wrote:
Hi Viktor,
Extending the code freeze doesn't help stabilize things. If we
have
important bugs for JBOD, we should mark those as blockers and
we'll
wait
until they are fixed if the fixes won't take too long (as usual).
Ismael
On Tue, Dec 19, 2023 at 11:58 AM Viktor Somogyi-Vass
<viktor.somo...@cloudera.com.invalid> wrote:
Hi all,
I was wondering what people think about extending the code
freeze
date to
early January?
The reason I'm asking is that there are still a couple of
testing
gaps in
JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which
I
think is
very important to finish to ensure a high quality release (after
all
this
supposed to be the last 3.x) and secondly the year end holidays
for
many
people are coming fast, which means we'll likely have less
people
working
on testing and validation. In my opinion it would strengthen the
release if
we could spend a week in January to really finish off JBOD and
do a
2 week
stabilization.
What do you all think?
Best,
Viktor
On Tue, Dec 12, 2023 at 2:59 PM Stanislav Kozlovski
<stanis...@confluent.io.invalid> wrote:
Hey!
Just notifying everybody on this thread that I have cut the 3.7
branch
and
sent a new email thread titled "New Release Branch 3.7" to the
mailing
list
<
https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh
.
Best,
Stanislav
On Wed, Dec 6, 2023 at 11:10 AM Stanislav Kozlovski <
stanis...@confluent.io>
wrote:
Hello again,
Time is flying by! It is feature freeze day!
By today, we expect to have major features merged and to
begin
working
on
their stabilisation. Minor features should have PRs.
I am planning to cut the release branch soon - on Monday EU
daytime.
When
I do that, I will create a new e-mail thread titled "New
release
branch
3.7.0" to notify you, so be on the lookout for that. I will
also
notify
this thread.
Thank you for your contributions. Let's get this release
shipped!
Best,
Stanislav
On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski <
stanis...@confluent.io> wrote:
Hey all,
The KIP Freeze has passed. I count 31 KIPs that will be
going
into the
3.7 Release. Thank you all for your hard work!
They are the following (some of these were accepted in
previous
releases
and have minor parts going out, some targeting a Preview
release and
the
rest being fully released as regular.):
- KIP-1000: List Client Metrics Configuration Resources
- KIP-1001: Add CurrentControllerId Metric
- KIP-405: Kafka Tiered Storage
- KIP-580: Exponential Backoff for Kafka Clients
- KIP-714: Client metrics and observability
- KIP-770: Replace "buffered.records.per.partition" &
"cache.max.bytes.buffering" with
"{statestore.cache}/{input.buffer}.max.bytes"
- KIP-848: The Next Generation of the Consumer Rebalance
Protocol
- KIP-858: Handle JBOD broker disk failure in KRaft
- KIP-890: Transactions Server-Side Defense
- KIP-892: Transactional StateStores
- KIP-896: Remove old client protocol API versions in Kafka
4.0 -
metrics/request log changes to identify deprecated apis
- KIP-925: Rack aware task assignment in Kafka Streams
- KIP-938: Add more metrics for measuring KRaft performance
- KIP-951 - Leader discovery optimizations for the client
- KIP-954: expand default DSL store configuration to custom
types
- KIP-959: Add BooleanConverter to Kafka Connect
- KIP-960: Single-key single-timestamp IQv2 for state
stores
- KIP-963: Additional metrics in Tiered Storage
- KIP-968: Support single-key_multi-timestamp Interactive
Queries
(IQv2)
for Versioned State Stores
- KIP-970: Deprecate and remove Connect's redundant task
configurations
endpoint
- KIP-975: Docker Image for Apache Kafka
- KIP-976: Cluster-wide dynamic log adjustment for Kafka
Connect
- KIP-978: Allow dynamic reloading of certificates with
different DN
/
SANs
- KIP-979: Allow independently stop KRaft processes
- KIP-980: Allow creating connectors in a stopped state
- KIP-985: Add reverseRange and reverseAll query over
kv-store
in
IQv2
- KIP-988: Streams Standby Update Listener
- KIP-992: Proposal to introduce IQv2 Query Types:
TimestampedKeyQuery
and TimestampedRangeQuery
- KIP-998: Give ProducerConfig(props, doLog) constructor
protected
access
Notable KIPs that didn't make the Freeze were KIP-977 - it
only
got
2/3
votes.
For the full list and latest source of truth, refer to the
Release
Plan
3.7.0 Document
<
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
.
Thanks for your contributions once again!
Best,
Stan
On Thu, Nov 23, 2023 at 2:27 PM Nick Telford <
nick.telf...@gmail.com>
wrote:
Hi Stan,
I'd like to propose including KIP-892 in the 3.7 release.
The
KIP has
been
accepted and I'm just working on rebasing the
implementation
against
trunk
before I open a PR.
Regards,
Nick
On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula <
mayanks.nar...@gmail.com> wrote:
Hi Stan
Can you include KIP-951 to the 3.7 release plan? All PRs
are
merged
in
the
trunk.
On Wed, Nov 15, 2023 at 4:05 PM Stanislav Kozlovski
<stanis...@confluent.io.invalid> wrote:
Friendly reminder to everybody that the KIP Freeze is
*exactly 7
days
away*
- November 22.
A KIP must be accepted by this date in order to be
considered for
this
release. Note, any KIP that may not be implemented in
time, or
otherwise
risks heavily destabilizing the release, should be
deferred.
Best,
Stan
On Fri, Nov 3, 2023 at 6:03 AM Sophie Blee-Goldman <
sop...@responsive.dev>
wrote:
Looks great, thank you! +1
On Thu, Nov 2, 2023 at 10:21 AM David Jacot
<dja...@confluent.io.invalid
wrote:
+1 from me as well. Thanks, Stan!
David
On Thu, Nov 2, 2023 at 6:04 PM Ismael Juma <
m...@ismaeljuma.com>
wrote:
Thanks Stanislav, +1
Ismael
On Thu, Nov 2, 2023 at 7:01 AM Stanislav
Kozlovski
<stanis...@confluent.io.invalid> wrote:
Hi all,
Given the discussion here and the lack of any
pushback, I
have
changed
the
dates of the release:
- KIP Freeze - *November 22 *(moved 4 days
later)
- Feature Freeze - *December 6 *(moved 2 days
earlier)
- Code Freeze - *December 20*
If anyone has any thoughts against this
proposal
-
please
let me
know!
It
would be good to settle on this early. These
will
be the
dates
we're
going
with
Best,
Stanislav
On Thu, Oct 26, 2023 at 12:15 AM Sophie
Blee-Goldman <
sop...@responsive.dev>
wrote:
Thanks for the response and explanations -- I
think the
main
question
for
me
was whether we intended to permanently
increase
the KF
--
FF
gap
from
the
historical 1 week to 3 weeks? Maybe this was
a
conscious
decision
and I
just
missed the memo, hopefully someone else can
chime in
here. I'm
all
for
additional though. And looking around at some
of
the
recent
releases,
it
seems like we haven't been consistently
following the
"usual"
schedule
since
the 2.x releases.
Anyways, my main concern was making sure to
leave a
full
2
weeks
between
feature freeze and code freeze, so I'm
generally
happy
with the
new
proposal.
Although I would still prefer to have the KIP
freeze
fall
on a
Wednesday
--
Ismael actually brought up the same thing
during
the
3.5.0
release
planning,
so I'll just refer to his explanation for
this:
We typically choose a Wednesday for the
various
freeze
dates -
there
are
often 1-2 day slips and it's better if that
doesn't
require
people
working through the weekend.
(From this mailing list thread
<
https://lists.apache.org/thread/dv1rym2jkf0141sfsbkws8ckkzw7st5h
)
Thanks for driving the release!
Sophie
On Wed, Oct 25, 2023 at 8:13 AM Stanislav
Kozlovski
<stanis...@confluent.io.invalid> wrote:
Thanks for the thorough response, Sophie.
- Added to the "Future Release Plan"
1. Why is the KIP freeze deadline on a
Saturday?
It was simply added as a starting point -
around 30
days
from
the
announcement. We can move it earlier to the
15th of
November,
but
my
thinking is later is better with these
things
- it's
already
aggressive
enough. e.g given the choice of Nov 15 vs
Nov
18, I
don't
necessarily
see a
strong reason to choose 15.
If people feel strongly about this, to make
up
for
this,
we
can
eat
into
the KF-FF time as I'll touch upon later,
and
move FF
a
few
days
earlier
to
land on a Wednesday.
This reduces the time one has to get their
feature
complete
after
KF,
but
allows for longer time to a KIP accepted,
so
the
KF-FF
gap
can
be
made
up
when developing the feature in parallel.
, this makes it easy for everyone to
remember when
the
next
deadline
is
so they can make sure to get everything in
on
time. I
worry
that
varying
this will catch people off guard.
I don't see much value in optimizing the
dates
for
ease
of
memory -
besides
the KIP Freeze (which is the base date),
there
are
only
two
more
dates
to
remember that are on the wiki. More
importantly, we
have
a
plethora
of
tools that can be used to set up reminders
-
so a
contributor
doesn't
necessarily need to remember anything if
they're
serious
about
getting
their feature in.
3. Is there a particular reason for
having
the
feature
freeze
almost
a
full 3 weeks from the KIP freeze? ...
having
3
weeks
between
the
KIP
and
feature freeze (which are
usually separated by just a single week)?
I was going off the last two releases,
which
had *20
days*
(~3
weeks)
in
between KF & FF. Here are their dates:
- AK 3.5
- KF: 22 March
- FF: 12 April
- (20 days after)
- CF: 26 April
- (14 days after)
- Release: 15 June
- 50 days after CF
- AK 3.6
- KF: 26 July
- FF: 16 Aug
- (20 days after)
- CF: 30 Aug
- (14 days after)
- Release: 11 October
- 42 days after CF
I don't know the precise reasoning for
extending the
time,
nor
what
is
the
most appropriate time - but having talked
offline to
some
folks
prior
to
this discussion, it seemed reasonable.
Your proposal uses an aggressive 1-week gap
between
both,
which
is
quite
the jump from the previous 3 weeks.
Perhaps someone with more direct experience
in
the
recent can
chime
in
here. Both for the reasoning for the
extension
from
1w
to 3w
in
the
last
2
releases, and how they feel about reducing
this
range.
4. On the other hand, we usually have a
full
two
weeks
from
the
feature
freeze deadline to the code freeze but with
the given
schedule
there
would
only be a week and a half. Given how
important
this
period is
for
testing
and stabilizing the release, and how vital
this is
for
uncovering
blockers
that would have delayed the release
deadline, I
really
think
we
should
maintain the two-week gap (at a minimum)
This is a fair point. At the end of the
day,
we have
to
take
time
out
of
either one of the 3 ranges (now - KF;
KF-FF;
FF-CF;)
*It sounds fair to me to take out half a
week
from
KF-FF
and
add
it
to
FF-CF*. e.g:
- KF=Nov 18 (Sat)
- FF=Dec 6 (Wed) 2.5w after
- CF=Dec 20 (Wed) 2w after
How do others feel about this?
Just to throw a suggestion out there, if
we
want to
avoid
running
into
the winter holidays while still making up
for
slipping
of
recent
releases,
what about something like this: ...
Looking at the last 2 releases, they both
had
a full
month
between
KIP
Freeze and Code Freeze to finish
contributions. Your
proposal
goes
back
to
a more aggressive 3 weeks e2e time. All
else
equal,
if
the
release
date
is
to be kept as early January, I would prefer
to
opt
for
the
more
accommodative 4-week period.
Note that historically, we have set all
the
deadlines
on a
Wednesday
and
when in doubt erred on the side of an
earlier
deadline
... We
can,
and
often have, allowed things to come in late
between
the
Wednesday
freeze
deadline and the following Friday, but only
on
a
case-by-case
basis.
This makes sense to me. The proposal I put
above puts
the two
critical
dates (FF & CF) on Wed to allow for this
flexibility
in
case
it's
needed.
Best,
Stanislav
On Tue, Oct 24, 2023 at 12:40 AM Sophie
Blee-Goldman
<
sop...@responsive.dev>
wrote:
Actually I have a few questions about the
schedule:
1. Why is the KIP freeze deadline on a
Saturday?
Traditionally
this
has
been on a Wednesday, which is nice
because
it gives
people
until
Monday
to
kick off the vote and give people a full
3
working
days to
review
and
vote
on it. Also,
2. Why are the subsequent deadlines on
different
days
of
the
week?
Usually
we aim to have the freeze deadlines
separated by an
integer
number
of
weeks. Besides just being a consequence
of
the
typical
1/2
week
separation
between freeze dates, this makes it easy
for
everyone
to
remember
when
the
next deadline is so they can make sure to
get
everything in
on
time.
I
worry that varying this will catch people
off
guard.
3. Is there a particular reason for
having
the
feature
freeze
almost
a
full
3 weeks from the KIP freeze? I understand
moving
the
KIP
freeze
deadline
up
to account for recent release delays, but
aren't we
wasting
some
of
that
gained time by having 3 weeks between the
KIP and
feature
freeze
(which
are
usually separated by just a single week)?
4. On the other hand, we usually have a
full
two
weeks
from
the
feature
freeze deadline to the code freeze but
with
the
given
schedule
there
would
only be a week and a half. Given how
important this
period
is
for
testing
and stabilizing the release, and how
vital
this is
for
uncovering
blockers
that would have delayed the release
deadline, I
really
think
we
should
maintain the two-week gap (at a minimum)
Note that historically, we have set all
the
deadlines
on a
Wednesday
and
when in doubt erred on the side of an
earlier
deadline, to
encourage
folks
to get their work completed and
stabilized
as soon
as
possible.
We
can,
and
often have, allowed things to come in
late
between
the
Wednesday
freeze
deadline and the following Friday, but
only
on a
case-by-case
basis.
This
way the RM has the flexibility to
determine
what to
allow
and
when,
if
need
be, while still having everyone aim for
the
established
deadlines.
Just to throw a suggestion out there, if
we
want to
avoid
running
into
the
winter holidays while still making up for
slipping
of
recent
releases,
what
about something like this:
KIP Freeze: Nov 22nd
Feature Freeze: Nov 29th
Code Freeze: Dec 13th
We can keep the release target as Jan 3rd
or
move
it
up to
Dec
27th.
Personally, I would just aim to have it
as
Dec 27th
but
keep
the
stated
target as Jan 3rd, to account for
unexpected
blockers/delays
and
time
away
during the winter holidays
Thoughts?
On Mon, Oct 23, 2023 at 3:14 PM Sophie
Blee-Goldman <
sop...@responsive.dev
wrote:
Can you add the 3.7 plan to the release
schedule
page?
(this -->
https://cwiki.apache.org/confluence/display/KAFKA/Future+release+plan
)
Thanks!
On Sun, Oct 15, 2023 at 2:27 AM
Stanislav
Kozlovski
<stanis...@confluent.io.invalid>
wrote:
Hey Chris,
Thanks for the catch! It was indeed
copied and I
wasn't
sure
what
to
make
of the bullet point, so I kept it.
What
you say
makes
sense
-
I
removed
it.
I also added KIP-976!
Cheers!
On Sat, Oct 14, 2023 at 9:35 PM Chris
Egerton <
fearthecel...@gmail.com>
wrote:
Hi Stanislav,
Thanks for putting this together! I
think the
"Ensure
that
release
candidates include artifacts for the
new
Connect
test-plugins
module"
section (which I'm guessing was
copied
over
from
the
3.6.0
release
plan?)
can be removed; we made sure that
those
artifacts
were
present
for
3.6.0,
and I don't anticipate any changes
that
would
make
them
likelier
to
be
accidentally dropped in subsequent
releases
than
any
other
Maven
artifacts
that we publish.
Also, can we add KIP-976 (
https://cwiki.apache.org/confluence/display/KAFKA/KIP-976%3A+Cluster-wide+dynamic+log+adjustment+for+Kafka+Connect
)
to the release plan? The vote thread
for it
passed
last
week
and
I've
published a complete PR (
https://github.com/apache/kafka/pull/14538
),
so
it
shouldn't be too difficult to get
things
merged
in
time
for
3.7.0.
Cheers,
Chris
On Sat, Oct 14, 2023 at 3:26 PM
Stanislav
Kozlovski
<stanis...@confluent.io.invalid>
wrote:
Thanks for letting me drive it,
folks.
I've created the 3.7.0 release
page
here:
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.7.0
It outlines the key milestones and
important
dates
for
the
release.
In particular, since the last two
releases
slipped
their
originally
targeted release date by taking an
average
of
46
days
after
code
freeze
(as
opposed to the minimum which is 14
days), I
pulled
the
dates
forward
to
try
and catch up with the original
release
schedule.
You can refer to the last release
during the
Christmas
holiday
season
-
Apache
Kafka 3.4
<
https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+3.4.0
-
to
see sample dates.
The currently proposed dates are:
*KIP Freeze - 18th November
*(Saturday)
*This is 1 month and four days
from
now -
rather
short -
but
I'm
afraid
is
the only lever that's easy to pull
forward.*
As usual, a KIP must be accepted
by
this
date
in
order
to
be
considered
for
this release. Note, any KIP that
may
not be
implemented
in a
week,
or
that
might destabilize the release,
should
be
deferred.
*Feature Freeze - 8th December*
(Friday)
*This follows 3 weeks after the
KIP
Freeze,
as
has
been
the
case
in
our
latest releases.*
By this point, we want all major
features to
be
merged &
us
to
be
working
on stabilisation. Minor features
should have
PRs,
the
release
branch
should
be cut; anything not in this state
will be
automatically
moved
to
the
next
release in JIRA
*Code Freeze - 20th December*
(Wednesday)
*Critically, this is before the
holiday
season
and
ends
in
the
middle
of
the week, to give contributors
more
time and
flexibility
to
address
any
last-minute without eating into
the
time
people
usually
take
holidays. It
comes 12 days after the Feature
Freeze.This
is
two
days
shorter
than
the
usual code freeze window. I don't
have a
strong
opinion
and
am
open
to
extend it to Friday, or trade off
a
day/two
with the
KF<->FF
date
range.*
*Release -* *after January 3rd*.
*It comes after a minimum of two
weeks of
stabilization,
so
the
earliest
we
can start releasing is January
3rd.
We will
move as
fast
as
we
can
and
aim
completing it as early in January
as
possible.*
As for the initially-populated
KIPs
in the
release
plan, I
did
the
following:
I kept 4 KIPs that were mentioned
in
3.6,
saying
they
would
have
minor
parts finished in 3.7 (as the
major
ones
went
out in
3.6)
- KIP-405 Tiered Storage
mentioned a
major
part
went
out
with
3.6
and
the
remainder will come with 3.7
- KIP-890 mentioned Part 1 shipped
in
3.6. I
am
assuming
the
remainder
will
come in 3.7, and have contacted
the
author
to
confirm.
- KIP-926 was partially
implemented
in 3.6.
I
am
assuming
the
remainder
will come in 3.7, and have
contacted
the
author
to
confirm.
- KIP-938 mentioned that the
majority
was
completed
and
a
small
remainder
re: ForwardingManager metrics will
come in
3.7.
I
have
contacted
the
author
to confirm.
I then went through the JIRA
filter
which
looks
at
open
issues
with
a
Fix
Version of 3.7 and added KIP-770,
KIP-858,
and
KIP-980.
I also found a fair amount of
JIRAs
that
were
targeting
the
3.7
release
but
consecutively had no activity on
them
for
the
past
few
releases.
For
most
of those, I pinged the author and
explicitly
asked
if
it's
going
to
aim
to
make it to 3.7. I have not
included
those
here
and
will
not
until
I
hear
confirmation.
Please review the plan and provide
any
additional
information
or
updates
regarding KIPs that target this
release
version
(3.7).
If you have authored any KIPs that
have an
inaccurate
status
in
the
list,
or are not in the list and should
be,
or are
in
the
list
and
should
not
be
- please inform me in this thread
so
that I
can
keep
the
document
accurate
and up to date.
Excited to get this release going!
All the best,
Stanislav
On Tue, Oct 10, 2023 at 9:12 AM
Bruno
Cadonna
<
cado...@apache.org
wrote:
Thanks Stan!
+1
Best,
Bruno
On 10/10/23 7:24 AM, Luke Chen
wrote:
Thanks Stanislav!
On Tue, Oct 10, 2023 at
3:05 AM
Josep
Prat
<josep.p...@aiven.io.invalid
wrote:
Thanks Stanislav!
———
Josep Prat
Aiven Deutschland GmbH
Alexanderufer 3-7, 10117
Berlin
Amtsgericht Charlottenburg,
HRB
209739
B
Geschäftsführer: Oskari
Saarenmaa &
Hannu
Valtonen
m: +491715557497
w: aiven.io
e: josep.p...@aiven.io
On Mon, Oct 9, 2023, 20:05
Chris
Egerton
<
fearthecel...@gmail.com>
wrote:
+1, thanks Stanislav!
On Mon, Oct 9, 2023, 14:02
Bill
Bejeck <
bbej...@gmail.com
wrote:
+1
Thanks, Stanislav!
-Bill
On Mon, Oct 9, 2023 at
1:59 PM
Ismael
Juma <
m...@ismaeljuma.com>
wrote:
Thanks for volunteering
Stanislav!
Ismael
On Mon, Oct 9, 2023 at
10:51 AM
Stanislav
Kozlovski
<stanis...@confluent.io
.invalid>
wrote:
Hey all!
I would like to volunteer
to
be the
release
manager
driving
the
next
release - Apache Kafka
*3.7.0*.
If there are no
objections,
I will
start
and
share
a
release
plan
soon
enough!
Cheers,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
--
Regards,
Mayank Shekhar Narula
--
Best,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
--
Best,
Stanislav
