The goal with these changes was to give users a clearer, more readable
interface, so we should present that interface up front and only
document the aliases as a backward-compatibility option.
I've renamed the envconfig tags to reflect the switch, but I left the
actual field names the same. I think they're sufficiently meaningful
inside the code, and leaving them unchanged avoids making a bunch of
churn in the rest of the code.
I don't love the mismatch between the helm.Config field (CleanupOnFail)
and the setting name (cleanup_failed_upgrade). I do think the setting
name should contain "upgrade" since it's specific to the upgrade command,
but if I make the config field CleanupFailedUpgrade, it becomes the new
longest field name, and gofmt creates a bunch of churn. Is that a good
enough reason...?
Just something I noticed while resolving a merge conflict. The "write
some docs" and "implement prefix" branches happened concurrently and
didn't get re-coordinated.
Helm2's --timeout took a number of seconds, rather than the
ParseDuration-compatible string that helm3 uses. For backward-
compatibility, update a bare number into a duration string.
As I skimmed through that section I noticed it wasn't immediately clear
whether a line of text was referring to the example above it or the one
below it.
It seems like this needs more information, like why you'd want to put
something in one stanza or the other, but I don't really know enough
about drone to give useful advice.
I was unhappy with the comments-in-yaml approach; it required
duplicating a lot of information and it was hard to find a balance
between "usefully thorough" and "readably concise.""
...Or at least, the namespace is passed around in helm's linting code. I
haven't proven that there's a case where omitting the namespace can
cause a linting problem, but I've seen enough to go ahead and document
the setting.
