Skip to content

CLI: Add deprecation mechanism for aliases #47419

Open
@MiYanni

Description

@MiYanni

Summary

I've began looking over the surface of the CLI and I'm beginning to recognize the inconsistencies. To allow us to "smooth over" these inconsistencies, we need a mechanism to mark aliases for deprecation. This primarily applies to aliases for now as explained by the process below.

Process

To deprecate things (commands/options/arguments), a process similar to this should occur:

  • Create an alias to the current thing and rename the actual thing
  • Add the deprecating mechanism to the alias
    • When the user uses the alias, they should get a deprecation message that this thing will be removed in a future update and they should use "other thing" instead.
    • Allow for an environment variable to disable these deprecation messages. By default, deprecation messages will be shown in interactive mode (see Chet's recent PR on detecting interactive mode) and deprecation messages will be disabled in non-interactive mode.

An additional check would be nice:

  • Create a unit test that can gather the deprecated items and check if they're no longer valid
    • Basically, we have an automatic process that when we update the repo version information, this unit test would tell us what is now deprecated or not, and we can decide to remove them.
      • To accomplish this, that means when deprecations are added, they need to be marked with a version number.
    • Work with Marc/Chet to figure out a good deprecation cycle and use that as the version check logic for deprecation messages.

Bonus points(?):

  • Allow a way to retrieve deprecated information for release notes

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions