-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Formalize how options are deprecated #4023
Copy link
Copy link
Closed
Labels
domain: configAnything related to configuring VectorAnything related to configuring Vectormeta: ideaAnything in the idea phase. Needs further discussion and consensus before work can begin.Anything in the idea phase. Needs further discussion and consensus before work can begin.needs: approvalNeeds review & approval before work can begin.Needs review & approval before work can begin.type: featureA value-adding code addition that introduce new functionality.A value-adding code addition that introduce new functionality.
Metadata
Metadata
Assignees
Labels
domain: configAnything related to configuring VectorAnything related to configuring Vectormeta: ideaAnything in the idea phase. Needs further discussion and consensus before work can begin.Anything in the idea phase. Needs further discussion and consensus before work can begin.needs: approvalNeeds review & approval before work can begin.Needs review & approval before work can begin.type: featureA value-adding code addition that introduce new functionality.A value-adding code addition that introduce new functionality.
It is inevitable that Vector will rename and reorganize configuration options, #3714 is the latest example. And while these changes are simple, they break backward compatibility and negatively affect UX. In the past we've simply aliased names so that we maintain backward compatibility, but we don't do this in a way that informs the user or marks the option as explicitly deprecated. This means it's unlikely we'll ever clean up this option.
I propose that we formalize how we deprecate options. It would be nice to create a single place where we define deprecated options. This place would perform the mapping as well as long deprecation warnings for users using these options.