There are a few common practices for marking features as experimental:

1. Setting a field in a config file, e.g. `experimental: true` that enables all features
2. A feature gates model that enables a subset of experimental or alpha features. Very similar to the first point. `feature-gates: ["oci", "fancy-feature"]`
   
3. Appending a prefix to the command, e.g. `helm experimental-registry ...`
4. The plugin model

Here's a list of projects used in production today that map to each of these features:

1. Docker CLI uses the --experimental flag: https://github.com/docker/docker-ce/blob/master/components/cli/experimental/README.md#use-docker-experimental
2. Kubernetes uses the feature gates model: https://kubernetes.io/docs/reference/command-line-tools-reference/
3. Cloud Foundry uses the prefixed model: https://docs.cloudfoundry.org/devguide/v3-commands.html
4. Helm currently has a plugin model. It has been used in the past for experimental work, but as Jimmy pointed out, it has stifled work that was intended to be added to
   

Right now I'm leaning towards the feature gates model. It provides users an opportunity to enable only the features they want to test without needing to enable *everything*, which may potentially break their UX. In other words, users may want to test one experimental feature, but another experimental feature may break their workflow in another way.

If this sounds good to others, I'll start hacking on an implementation of the feature gates model and put the OCI work behind a feature gate. That way we can start playing with the idea to see if that's the model we want to move forward with.

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

---

From: cncf-helm@... <cncf-helm@...> on behalf of Matt Farina via Lists.Cncf.Io <matt=mattfarina.com@...>
Sent: Tuesday, August 6, 2019 9:59 AM
To: cncf-helm@... <cncf-helm@...>
Cc: cncf-helm@... <cncf-helm@...>
Subject: Re: [cncf-helm] How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

 

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.