Give consumers a means to opt-out of minor breaking changes

[gejohnston]

Is your feature or enhancement request related to a problem or limitation? Please describe

Add a means for consumers to opt-out of features that would be breaking changes in the current release, but also might be very desirable.

Describe your enhancement idea

As the team adds functionality that might be marginally breaking, provide a means to allow users to opt-out of each breaking change that adversely affects their existing programs or procedures.

Describe alternatives you've considered

In V2, a class named zowe-cli\packages\imperative\src\utilities\src\NextVerFeatures.ts provided a means to opt-in for different features using environment variables. Since the only such V2 feature was included in V3, the NextVerFeatures class is not currently used. That class could be used as the infrastructure for implementing a similar capability in V3.

Instead of environment variables, we could add a new object to zowe.config.json to allow users to opt-out of each new feature. The trouble with an opt-in approach is that consumers may not even be aware that the new feature is available, so they do not know to opt-in. With an opt-out approach, the consumer would automatically get the new feature. If it causes a consumer problems, they could then opt-out.

We could document the new feature name in the changelog entry for such a feature, so that the user can opt-out of the feature.

We could place a new object in zowe.config.json to hold any opt-out features - something like this:

// The following enhancements introduce a minor change in the behavior of earlier releases.
// If you encounter problems from a new feature, you can choose to disable any such feature by setting its value to false.
// If a feature name is not specified in the list below, we assume a value of true.

useFeature{
    removePromptInSshOutput: false,    // zowe no longer displays an extraneous '$' in the output of ssh commands
    removeFileDoesNotExistErrMsgOnDelete: true    // zowe no longer gives an error when deleting a non-existent file
}

We could consider adding a new zowe config features command. It would display all current feature names. A consumer could run the zowe config features command to get the most up-to-date list of feature names. With the --rfj flag maybe we display a fully populated useFeature object that a consumer could place into their zowe.config.json file.

Another possibility is for the zowe config init command to place a fully populated useFeature object into zowe.config.json.

Provide any additional context

We could update the sample object in this issue as a means to track all such breaking change candidates as we think of them.

[github-actions]

Thank you for raising this enhancement request.
The community has 90 days to vote on it.
If the enhancement receives at least 5 upvotes, it is added to our development backlog.
If it receives fewer votes, the issue is closed.