CLI undocumented and breaking changes

[mail.deliverability.test]

It seems Imunify360 4.2.6-4. introduces breaking changes in the CLI for malware scanning. The following worked until the most recent update: [code type="markup"]/usr/bin/imunify360-agent malware on-demand start --intensity low --path /home*/* --no-follow-symlinks[/code] After the update, this fails with the following error: [code type="markup"]imunify360-agent malware on-demand start: error: ambiguous option: --intensity could match --intensity-io, --intensity-cpu, --intensity-ram[/code] The new options are not documented at https://docs.imunify360.com/command_...rface/#malware, which still lists the old --intensity option. This is not the first instance of a feature being broken in this way. There are other features in the documentation which dont match the current behavior, for example "submit false-positive" which requires additional arguments not listed in the documentation. Would it be possible for the development team to avoid making breaking changes to the command line options whenever possible? We are trying to use the CLI to script some very basic actions with your product, for example a periodic scan of all home directories. It is very difficult to do this when the documentation does not accurately describe the product behavior, and we cannot rely on a documented CLI option to work from one version to the next. We use your CLI for this because it supports more fine-grained behavior such as exclude masks which arent supported by the "Background Scanning" feature. IMHO the correct thing to do when introducing the new intensity options, would have been to support the old `--intensity` syntax and translate it to the new functionality. Or if nothing else, accept the old syntax without throwing a fatal error. In the rare situations when an existing feature or syntax is broken or dropped entirely, or where using it as documented will now result in a fatal error, this should get a prominent notice in release notes. Once you have documented a feature, you should assume that your user base is using it and will not be happy if it suddenly breaks without warning. I think these are univerally accepted as best practices for software development and release cycles, so hopefully you can understand my frustration with the change in behavior .

[atishin]

Hi John,

starting from version 4.2 the --intensity option has been split to --intensity-cpu and --intensity-io. Both take an integer as a value from 1 (lowest) to 7 (highest). --intensity-ram has no effect right now and its going to be implemented in the future.

The documentation will be updated soon.

Thank you!

[mail.deliverability.test]

Hello,

Thank you for your response and explanation.

Yes, I understand all of this. My problem is that this change has broken the old documented functionality. Your CLI provides JSON output and thus is intended to be used as an API, correct? Breaking changes to an API should not happen in a minor release of any software project (and they should be rare even in major releases). And breaking changes should never be released undocumented.

In this case Ive already updated our scripting which uses the feature, but could you please confirm that this feedback has been received by the development team?

[mail.deliverability.test]

> please accept my apologies for this backward incompatibility. Thats not supposed to happen and were going to fix it. So we will introduce new parameters as well as keep the old one as before. Dev team is working on that.

Thank you for this, its very much appreciated!

[skhristich]

Hello John! Happy to hear it and thanks for following up! If you have any other questions, feel free to ask here.
Thank you for contacting us.