Replace --force flag with --dev-release? about bosh-cli HOT 7 CLOSED

Replacing it would be backwards-incompatible, and I would strongly veto that.

from bosh-cli.

As an alias and deprecate force?

from bosh-cli.

Alias, maybe. Deprecate, definitely not.
[And I say "maybe" because I don't know if the alternative spelling is the best one, and am not sure that the --force flag is actually a problem. Making an alias of a nicely-named flag, if the current one is a problem is something I'd support.]

from bosh-cli.

@Benjamintf1, Aliasing --force by --dev-release does not seem to be a good idea since --force is not equivalent of building a dev release. It only deactivates the git dirty state check and --final and --force flags are not mutually exclusive.

Another possible approach could be to disable dirty git check by default when building a dev release (ie. flag --final not given). The idea behind this being:

• when I want to build a final release: I'm glad that git dirty state is checked and I can deactivate it if needed
• when I want to build a dev release: I just want my tarball, I don't care about git, generated files aren't even known to git

from bosh-cli.

I guess I'm forgetting that dev-release is it's own concept and can be finalized too. Perhaps --dev-release is a poor overloaded term here.

I do worry the degree i've seen --force --final out in the field and I wonder if changing the flags that are used could discourage these sort of patterns.

I don't want to distract yall too much, It's just something that's been rolling around the back of my head.

from bosh-cli.

I also agree that the change should be backwards compatible. Looking into the bosh create-release --help the --force flag explanation is quite clear Ignore Git dirty state check. The dirty state of the git repository could have an affect to the generated bosh-release that is why I think is a good idea to require explicit confirmation from the user that it is OK to ignore the dirty state. Even removing the check only for the dev releases is backwards-incompatible change and I'n not sure whether we should go that way. If yes, at least we should print a warning during the release generation.

from bosh-cli.

It feels like this discussion has reached its natural conclusion and no further actions are needed.

from bosh-cli.