1. posterid:705694
  2. How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Re: How to handle experiment of Helm charts in OCI repos when 3.0.0 comes out

Matt Fisher <matt.fisher@...>
 

An environment variable seems to be the right approach. Either that or a config file similar to Docker's config.json.

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...>
Sent: Tuesday, August 6, 2019 11:53 AM
To: Matt Farina <matt@...>; jimmyzelinskie@... <jimmyzelinskie@...>
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 thought following semver on the Go API for v3 was a given.

Absolutely. I'm specifically talking about the stability of pkg/registry, which is the package used primarily for communicating with OCI registries.

The question I'm wondering is "If we're marking certain features of the client as experimental, should the SDK receive the same treatment? If so, how?"

1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada

From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <jimmyzelinskie=gmail.com@...>
Sent: Tuesday, August 6, 2019 10:04 AM
To: Matt Farina <matt@...>
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

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@...> wrote:
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 -----
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.
Join {cncf-helm@lists.cncf.io to automatically receive all group messages.