Should patrol_cli and artifacts be versioned separately?

[bartekpacia]

Currently, AutomatorServer/ios and AutomatorServer/ios are very tightly tied to patrol_cli.

Problem that the current approach causes:

• if we want to make any change to Automator Server, we have to release a new version of patrol_cli
• patrol_cli's changelogs are bigger and doesn't necessarily concern patrol_cli itself
• label patrol_cli is ambiguous. For example, features such as Toggle Wi-Fi on iOS #322 require work on patrol, the Dart package, and the native iOS automation server living in AutomatorServer/ios. Assigning it only a patrol label is insufficient, assigning patrol and patrol_cli is incorrect, because Toggle Wi-Fi on iOS #322 doesn't actually require any work on the CLI side. We could create new labels (automator-ios or automator-android) but still, to make them publicly available, we have to update the CLI.

Or maybe there is some other way to structure the project. I'm very open to ideas.

Related (supercedes?) to #309

cc: @mateuszwojtczak @jakubfijalkowski

[mateuszwojtczak]

IMO native servers are not a part of CLI

[jakubfijalkowski]

Completely agree.

[bartekpacia]

TL;DR

I'd say that native automators are separate from the CLI. Their version would not be the same as patrol_cli's version. They would be versioned separately.