Just so everyone has reference, Steve is referring to the fact that the "chart" and "registry" subcommands in Helm 3 are hidden behind an experimental env var. For more info, please see this doc:

Now that we have artifacts accepted as an OCI project, what is the thought process to pull this out of experimentation? This isn’t as much a chicken/egg scenario as cart/horse. Registries will

Just wanted to chime in! this is great, I just did a quick run through of it with some examples and it worked great. I look forward to getting some time to really dig into it.

Sure thing! It has been added to the agenda for this week: https://docs.google.com/document/d/1d-6xJEx0C78csIYSPKJzRPeWaHG_8W1Hjl72OJggwdc -Taylor

Of course, this weekend’s developer calls should be ok. Just remember to give me some minutes on the meeting Get Outlook for iOS

Ok, I finally had a chance to take a look at this and it looks really good, especially for tracking along with the Helm 3 alpha releases. Is this something you'd like to demo during one of the Helm

I read through the source yesterday, and this is looking good! Several people from WeaveWorks were interested in pursuing this idea as well. Hopefully some are on this list and may be able to take a

Thanks for letting us know about this! We are currently working on the finishing touches for the first beta, so I will take a better look at this next week.

Hi folks, I've been looking into peribolos, a tool used at the Kubernetes org, for automating our Helm GitHub organization & team membership. Basically this means the Helm organization config will be

Hello everyone, i want to introduce a new project https://github.com/alauda/captain related to Helm3. It’s a controller based on the helm3 code, and defines several CRDs (HelmRequest, Release,

Yes numerous services. I have two objectives. One is to make software in loop testing of drones more reproducible and the other is to create a scalable system to study network interaction.

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

Hi All, I was advised to ask here regarding complex helm chart development. I'm trying to put together a new flight simulation system and this means a lot of inter-node communication through things

Hello everyone, i want to introduce a new project https://github.com/alauda/captain related to Helm3. It’s a controller based on the helm3 code, and defines several CRDs (HelmRequest, Release,

An environment variable seems to be the right approach. Either that or a config file similar to Docker's config.json. Matthew Fisher Caffeinated Software Engineer Microsoft Canada

> 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

>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

The feature gates approach sounds good to me. In general, I’m in favor of keeping the work in tree and marking experimental (vs. plugin). @Matt when/where would the feature gates be configured? On

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

The other aspect we may want to consider is the SDK. In Helm 2, we had a strict backwards compatibility contract for the Go SDK. Anything that was made public could not be changed from Helm 2.0.0