feat: new option to suppress 0.4 deprecation warnings

[sxyazi]

An implementation of the feature request: #2026

Closes #2026

# yazi.toml
[manager]
_v4_suppress_deprecation_warnings = true

[uncenter]

Why is this version specific? Wouldn't it make sense to have it as a permanent field?

[sxyazi]

You mean using suppress_deprecation_warnings instead of _v4_suppress_deprecation_warnings?

The issue with this is that if a user enabled it in v0.4 and forgot to remove it, since it's not version-specific, they won't even see the deprecation warnings for the v0.5 API when they upgrade to v0.5.

As a result, they might run into issues when the v0.5 API compatibility layer is completely removed, without realizing it.

[uncenter]

This seems like a hack though. Maybe "suppress_deprecation_warnings" has a value like "0.4" where it targets warnings in that range? Just something more dynamic. I'd hate to see this be removed and then requested again and brought back for v5... etc.

[sxyazi]

My plan is to remove this option when removing the 0.4 compatibility layer, since it feels weird to still have a suppress_deprecation_warnings if all the compatibility code (warnings) is gone as there's nothing left to "suppress".

If we're going to make it permanent, we'd need to reconsider its name and position, placing it under [manager] feels odd.

Like the [headsup] and disable_exec_warn option introduced in 0.3, which were eventually removed along with the compatibility code though.

Overall, I think making it permanent is a bit of an overkill, especially since it's just a temporary workaround for the transition.

[uncenter]

Speaking as the person who edits the schemas adding all these temporary config options is not a good solution 😅
Maybe add an option in the TUI itself that toggles an internal state property, so outside of the config? It can be like this, for a specific version, and cleared by Yazi by later versions.