To answer to the question in the title of this submission:
You should not. As soon as a feature has got released to all users of a software, you won't be able to disable it without some users becoming really dissatisfied.
The solution is not to release a new feature to all users.
Before even thinking about releasing a new feature, first ask yourself:
What is the goal of this new feature?
The answer to that question is your hypothesis, you need to try to answer by experimenting.
That is, perform an A/B-test:
Launch the feature to a subset of your users and check if it achieves its goal.
This goal must of course be measurable and ideally there are KPIs that you can use to check the success or failure of your experiment.
When the experiment is successful you deploy the feature for all users.
If the experiment fails, you remove it for the subset of users and the rest will never know about it.
This also helps the codebase to stay clean, features not making it into the product, is code not making it into your codebase, which means less code to maintain, less complexity.
You should not. As soon as a feature has got released to all users of a software, you won't be able to disable it without some users becoming really dissatisfied.
The solution is not to release a new feature to all users.
Before even thinking about releasing a new feature, first ask yourself:
What is the goal of this new feature?
The answer to that question is your hypothesis, you need to try to answer by experimenting. That is, perform an A/B-test:
Launch the feature to a subset of your users and check if it achieves its goal. This goal must of course be measurable and ideally there are KPIs that you can use to check the success or failure of your experiment.
When the experiment is successful you deploy the feature for all users. If the experiment fails, you remove it for the subset of users and the rest will never know about it.
This also helps the codebase to stay clean, features not making it into the product, is code not making it into your codebase, which means less code to maintain, less complexity.