On 06/22/2011 01:47 PM, Heiko Braun wrote:
I wouldn't mind if the command stays the way it is.
But then the operation name on a deployment needs to be changed.
For instance to :enable and :disable opposed to :deploy, because that already
taken by the command name.
It would make sense, because the deployment carries and attribute name
"enabled" already.
This makes sense. And probably will be consistent with other things.
E.g. data sources chose enable/disable as names.
If just look at the CLI on it's it makes perfect sense they way
you build it.
But if regards the operation, the CLI commands, and the model description
you will realize that all three diverged at some point and rely on their own specific
terms.
Agreed, they should be aligned where possible. Although there will still
be some differences, since higher level commands might translate into
different operations (including composite) depending on the conditions
and arguments.
The new approach to commands I am working on right now will help with this.
Alexey
Ike
On Jun 22, 2011, at 1:18 PM, Alexey Loubyansky wrote:
> Just re-naming the current deploy command to upload doesn't sound nice
> to me.
> Because the command actually deploys the package (unless you add
> --disabled). So, it's as clear as it can be.
>
> Renaming just to match an operation name doesn't justify it for me in
> this case. It may also do a full-replace if --force is specified, btw.
>
> So, if we were to re-name the command we would have to review the
> arguments too.
> Would 'upload' enable by default? Or it would only if --enable is
> specified (with server groups in the domain mode)?
> Should enable be a separate command? Which would accept server groups,
> etc? This would mean two commands instead of one to actually deploy an app.
>
> What would "undeploy" be renamed to? "remove" seems to be too
general.
> unload? remove-deployment?
>
> Alexey