Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out
There are a few common practices for marking features as experimental:
Here's a list of projects used in production today that map to each of these features:
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.
Caffeinated Software Engineer
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:
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: