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

From: jimmyzelinskie+cncf@...

To: Matt Farina <matt@...>

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

Hey there,

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.