Replace --force flag with --dev-release?

[Benjamintf1]

--force feels like it's ignoring errors, or deleting things. Really maybe this flag should be --dev-release.

It would also rightly discourage people from using the --force flag "to just stop the errors" and instead make them recognize what they're doing is not creating a production ready release?

[klakin-pivotal]

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

[Benjamintf1]

As an alias and deprecate force?

[klakin-pivotal]

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.]

[psycofdj]

@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

[Benjamintf1]

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.

[beyhan]

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.

[rkoster]

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