There are a few common practices for marking features as experimental: Setting a field in a config file, e.g. `experimental: true` that enables all features A feature gates model that enables a

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

FYI... this was meant to go to the list (per Jimmy in slack) so forwarding on...

One of the features being developed for Helm v3 is the ability to store Helm charts in OCI container image repositories (by following the distribution spec). You can think of these as repositories

As part of the OCI work I would expect the calls to things like `helm install` to work transparently to the user. This is for the UX. Attachments: Outlook-1504220459.png

Sure - I think what I'm getting at is on the client side we may need to determine whether the ref in question is a traditional .tgz or if hosted on a registry. Requesting a chart from registry is not

Josh, What I suggested would require a redirect in monocular. I don't believe a change needs to happen in Helm unless there is a problem with it following redirects. The Helm CLI would not need to

+1

This is all great - just want to keep in mind how this will work alongside registry-based charts, where URL is always the ref being used. Perhaps we have a HEAD/GET request to check to see if the url

Yeah I like that! So if a "browser" identifies itself as the helm client and connects to a monocular URL, the repo software should give a 302 [temp] redirect to the tarball of the latest

That would be a great approach! It wouldn't be too difficult for monocular to handle those requests and redirect them accordingly to the right .tgz. It would probably need to support

We are currently discussing the support proposal for Helm v2 once Helm v3 is released. There are two reasons for this: We want to have a shared understanding about levels of support over time so

The timing for this is good. I wonder if Monocular (the software that powers the helm hub) could intercept a call to it based on the client and perform a redirect to the right package file. This could

Completely agree, I previously brought up the idea of using some sort of vanity URL to make it easier to install charts listed on the Helm Hub

While I understand the stated reasons for removing the stable repository, I'm a great believe in decreasing the time to dopamine for using a new tool. For better or worse being able to run `helm

Welcome to the Helm Community! I recently took my friend JJ through getting started with Helm and he streamed it to twitch and then uploaded to youtube. If you want to watch us go from zero to

On init, does it at least point folks to the hub.helm.sh site so they can find things easier? Thanks, Kevin

Great question. Two things come to mind. 1) We have a line item to "Remove helm init and support XDG Base Directory" that hasn't happened yet. This should be a fairly straight forward to implement if

When you initialize Helm it has long added the stable repository. Unless overridden it is set to https://kubernetes-charts.storage.googleapis.com/. Even though Helm is designed to work with numerous

Hi, Welcome to Helm. Documentation is a good place to start. The current release is Helm v2 and the documentation is at: https://helm.sh/docs/. The Helm community README provides a lot of good