meta_desc: "Full access to Helm features, new & updated commands in the Pulumi CLI, plugin installation options in .NET Automation API, and schema check for Pulumi Packages"
- [Dynamic providers in Python can now given a custom name](/blog/pulumi-release-notes-m61#dynamic-providers-in-python-can-now-given-a-custom-name)
- [Automation API in .NET can use plugin installation options `exact` and `server`](/blog/pulumi-release-notes-m61#automation-api-in-net-can-use-plugin-installation-options-exact-and-server)
- [Schema checker for Pulumi Packages](/blog/pulumi-release-notes-m61#schema-checker-for-pulumi-packages)
- [Organization invites now send you to the correct identity provider](/blog/pulumi-release-notes-m61#organization-invites-now-send-you-to-the-correct-identity-provider)
Pulumi's existing Helm `Chart` resource provides support for deploying Helm charts via templating the chart and deploying it as Pulumi resources. This means that some features of Helm that are not availabe via Helm templating do not behave quite the same using the Pulumi Helm `Chart` resource as they do when deployed via the `helm` CLI itself - for example features like [Helm lifecycle hooks](https://helm.sh/docs/topics/charts_hooks/) and handling sub-charts and [dependencies](https://helm.sh/docs/topics/charts/#chart-dependencies). As Helm and its usage evolved over the years, Pulumi users using the `Chart` resource have noted that in many cases they would like a resource that provides the exact same behave as the `helm` CLI, but can be orchestrated as part of a Pulumi deployment.
The new [Helm `Release`](/registry/packages/kubernetes/api-docs/helm/v3/release) resource provides Pulumi users more options to choose the right tool for their use-case. In contrast to the existing Helm `Chart` integration, which is implemented as a Component Resource that extracts the corresponding Kubernetes resources' manifests from the chart and installs them as if they were individually specified in the Pulumi user program, the new Helm `Release` resource uses the Helm SDK directly to perform the deployment, providing the exact same behavior as a corresponding `helm` CLI deployment.
You can get started with the Helm Release resource in versions [v3.7.0](https://github.com/pulumi/pulumi-kubernetes/releases/tag/v3.7.0) and higher of the Pulumi Kubernetes Provider and SDK in all Pulumi supported languages.For example, in the following snippet we install Redis through a Helm Chart:
You can now use Pulumi's modern infrastructure-as-code solution to manage new resources! Our new provider for MinIO gives you access to the full range of high-performance, S3-compatible object storage offered by [MinIO](https://min.io). Likewise, our new provider for Snowflake lets you create and manage many of the data engineering, data lake, data warehouse, and other data resources in [Snowflake's](https://snowflake.com) data cloud.
We shipped new versions of the Azure Native provider (1.22.0 through 1.28.0) that collectively added 15 new resources across services like SQL Server, Kusto, DocumentDB, and Power BI that you can now manage with the Azure Native provider.
In this milestone, we shipped Pulumi versions [3.10.2](https://github.com/pulumi/pulumi/releases/tag/v3.10.2) through [3.12.0](https://github.com/pulumi/pulumi/releases/tag/v3.12.0). The full list of changes in each version is available [in the changelog](https://github.com/pulumi/pulumi/releases); read on to learn about some of the biggest changes.
### New `pulumi about` command for easier troubleshooting
To make it easier to troubleshoot errors in the Pulumi CLI, we've added a new `pulumi about` command that collects useful information like the plugins you have installed, the OS and architecture you're running, the backend that's storing your state, your CLI version, and more.

[Learn more in this GitHub issue](https://github.com/pulumi/pulumi/issues/2715)
### `pulumi config set` hides secret values
Previously, setting a config value using `pulumi config set` would write the value to `stdout`, which could be undesirable if the config value was a secret. Now, config values that look like secrets will be hidden and the config key name will be written to `stdout` instead.
Thanks [@JasonWhall](https://github.com/JasonWhall) for contributing this change!
[Learn more in this GitHub PR](https://github.com/pulumi/pulumi/pull/7327)
### Dynamic providers in Python can now given a custom name
When building a dynamic provider, it can be useful to give the provider a name so that at runtime, you can identify which provider is actually making a change. Previously, it wasn't possible to do so in Python. Now, you can pass a `name` parameter to the dynamic provider's constructor:
When running Pulumi interactively, you can use the [`pulumi plugin install` command](/docs/cli/commands/pulumi_plugin_install) to manually install plugins required by your program, possibly from a server where you host your own plugins. You can now do the same task in the .NET Automation API:
When authoring a Pulumi Package, it can be helpful to validate that your [schema](/docs/using-pulumi/pulumi-packages/schema/) is correct. Now, you can validate your schema by running the [`pulumi schema check` command](/docs/cli/commands/pulumi_schema_check).
[Learn more in this GitHub PR](https://github.com/pulumi/pulumi/pull/7865)
## Pulumi Service and Pulumi.com
### Organization invites now send you to the correct identity provider
Previously, when you invited a collaborator to your organization, that collaborator needed to know which identity provider (email, GitHub, GitLab, Bitbucket, or SAML SSO) that your organization uses in order to sign up correctly and get access to the organization. Now, any invites you send will direct your new collaborator to the correct identity provider automatically.
