Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Jimmy Zelinskie <jimmyzelinskie@...>
toggle quoted messageShow quoted text
>I think what Jimmy is suggesting fits in with the first option
Yup! I wasn't sure if the intent of the first option was to simply put the string `(experimental)` next to the usage and call it a day or not.
The Go compiler has been using environment variables for feature gating (e.g. GOMODULES111=on). Having to append `--experimental` to commands seems monotonous for those testing the functionality, although that might be desirable so that if anyone sees the bash history (or is shown the command) it's extremely clear that the work isn't stable.
On Tue, Aug 6, 2019 at 12:59 PM Matt Farina <matt@...
I think what Jimmy is suggesting fits in with the first option of:
1) To document the feature as experimental in the CLI and in the
documentation. Breaking changes may (likely?) happen to support the
final implementation. It would not fall under Helms use of SemVer
until it is no longer an experiment. We would likely not expose it via the usage information until it was ready.
In this case the usage would be hidden from the CLI until it's ready. I think we need to have it characterized as experimental and not following the SemVer guarantee so as not to confuse people who have used it. This way everyone is clear that could break and isn't following SemVer.
Do we hit it behind a flag of something like `--experimental`?
On Tue, Aug 6, 2019, at 11:54 AM, Matt Farina wrote:
FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...
----- Original message -----
Subject: Private: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
Date: Tuesday, August 06, 2019 11:49 AM
I'd like to propose a third option which is to continue the existing work, but hide it from the CLI usage by default. This will allow continued development, but without user confusion. I'd argue that even if you tell people that the functionality is experimental, it'll confuse people unless they have to explicitly opt in somehow (e.g. export an environment variable).
While pulling out into a plug-in is a noble goal, App Registry was stifled a lot by the limitations of the plug-in model, which only compounded the difficulty of getting feature functionality finished. I think getting core functionality implemented first should be the priority and then a later version of Helm could focus development on pulling out as many features as possible into plug-ins.
Join firstname.lastname@example.org to automatically receive all group messages.