docs/adrs/deprecating-and-removing-flags.md
Date: 2022-07-20
Accepted
Upstream Kubernetes has a flag deprecation policy. For admin-facing components, flags must function for at 1 minor release after their deprecation before they are removed.
Historically, the policy around removing flags was to maintain flag compatibility for two minor releases before making any breaking changes. For example, flag would be:
This policy was not well documented and was tribal knowledge.
Currently, we have several flags that are no longer used. These have been labelled as deprecated. However, we have failed to maintain the historical policy and have not removed the flags, even after multiple minor releases. This creates a problem where we aren't really deprecating flags, because they are always kept around.
The following system will be implemented for deprecating and removing flags:
An example of the proposed system:
--foo exists in v1.23.10 and v1.24.2.--foo in favor of --new-foo.--foo continues to exist, but will warn users "--foo will be deprecated in v1.25.0, convert to using --new-foo". --foo will continue to exist as an operational flag for the life of v1.23 and v1.24.--foo is marked as deprecated in documentation and will be hidden in code. It will continue to work and warn users.--foo will cause a fatal error if used. The error message will say --foo is no longer supported, use --new-foo.--foo will be removed.This enables us to completely remove depreciated flags. This long process has minimal risk as the timelines for deprecation and removal are well-defined and explained to the user.
One downside is that it will take quite a while (2 minor releases) to completely remove flags.