s/not/now .... Helm v3.1.0 has NOW been released. Thanks for catching my typo Jimmy.

Helm v3.1.0 has not been released. You can read about it at https://github.com/helm/helm/releases/tag/v3.1.0 There was about 3 months between the release of 3.0.0 and 3.1.0. The release of 3.0.0 was a

Part of the process for Helm to become a graduated CNCF project is to complete an independent and third party security audit with the results being published. As part of the audit of Helm 3 a security

If you are going to work with both Helm v2 and Helm v3 in your scripts this email is where we are looking for your input. `helm version` in v2 and the forthcoming v3 work a little different. This incl

+ Steve

Steve, you ask a great question here. Specifically... At KubeCon/CloudNativeCon EU this year we learned that there is good demand for Helm v3 sooner rather than later. Specifically, a Helm without Til

Hi Joni. Is this flight simulation system one application with numerous microsevices? If so, it may make sense to do it as a single chart. That's what I would do. Are you going to share this chart pub

I thought following semver on the Go API for v3 was a given. I think it's important with the way Go modules don't allow you to set a high end for the range resolution for minor versions. The tooling b

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 no

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 lik

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.

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 fig

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 there

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

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 d

Kubernetes has an API deprecation policy. The extensions/v1beta1, apps/v1beta1, and apps/v1beta2 APIs are long past their deprecation window. They are now being deprecated. In Kubernetes 1.16 (the nex

The CNCF put out a transparency report for this past EU conference. One of the things that caught my attention was that of the CNCF projects only Kubernetes and Prometheus had more interest than Helm

Consider this email an invitation to get involved. Wouldn’t it be good if Helm was better with CRDs? Helm currently has the `crd-install` lifecycle hook. In charts we can use the Capabilities to detec