o-nikolas commented on code in PR #36250:
URL: https://github.com/apache/airflow/pull/36250#discussion_r1445117071
##########
airflow/config_templates/config.yml:
##########
@@ -944,6 +944,14 @@ metrics:
description: |
StatsD (https://github.com/etsy/statsd) integration settings.
options:
+ metrics_use_fuzzy_match:
Review Comment:
>This is the primary reason I think moving over to two new configs that
replace old configs as better. This way when the old config is deprecated,
users who adopted the new configs wouldn't have to make any change at all.
But now isn't this adding even more new configs than Dennis's original
proposal?
Ultimately, I agree that we should change the definition of the current
configs and add nothing new (zero new configs added) but we also do need _some_
way to give people fair warning. I think we should try do that with adding as
few, if any, configs as possible. So I'm in slight favour of Dennis's proposal
since it only adds one new config, which will be dropped after the deprecation
process/switch over. Another approach could be a version check in the code that
says something like "the behaviour of these configs will change by release
<foo>, please be prepared to update your configuration at that time" (or a
better message since I just spit balled that right now...) and uses the old
beahviour if the code is before the release where we switch, and later releases
it uses the new behaviour.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
