Hi David,
Thank you very much for pointing out this, we didn’t mention the deprecation
period for this change, since the `incrementalAlterConfigs` api can achieve all
the capabilities of `alterConfigs` api (though it’s a best-effort approach,
currently it’s 100% achievable in practice), which m
Hi Ziming,
I just read the KIP again and I don't see any deprecation period mentioned
in the KIP. Where is it? I only see that we wanted to have a failback prior
to 4.0 and we wanted to remove it in 4.0. However, I don't see anything
mentioning that we would actually warn the user about it.
Best,
Hi David,
In the original scheme of KIP-1011, we were going to maintain a deprecation
period before 4.X, which means we won’t fail directly before 4.X, this is
consistent with what we have done in KIP-894, currently the PR is not landed
onto release-3.9, so there would be no deprecation period
Hi Ziming,
I am not sure to understand the concern. What's wrong with keeping the
original plan? If I understood it correctly, the plan was to fail
directly if the incrementalAlterConfigs API is not available in 4.x
versions. The new API was introduced in AK 2.3. The likelihood of using the
update
Hi Kafka devs, I have initiated KIP-1011 in which we have concluded that we
will replace deprecated `alterConfigs` with `incrementalAlterConfigs` in
command line tool `CommandConfig`. In the design, if the server doesn’t
support `incrementalAlterConfigs`, we would fallback to `alterConfigs` fo
Hi Ziming,
We should go through the depreciation period before removing/failing it.
I remember the `alterConfigs` will still exist in v4.0.0, right? If so, I
think we should go with option (1).
Thanks.
Luke
On Thu, Nov 14, 2024 at 2:38 PM ziming deng
wrote:
> Hi Kafka devs, I have initiated K
