First, apologies getting this out so late into the year.\nWe’ve been very busy and just found the time to write this update.<\/p>\n
We continue to treat security as a top priority and as issues are discovered or reported,\nwe will continue to prioritize these issues over new feature development.<\/p>\n
We continue to fix various reported issues, as well as prioritizing the review and merging of community pull requests.\nBased on community feedback, we’re now using a GitHub project<\/a> to provide transparency\non which issues and pull requests team members are focusing on.<\/p>\n PowerShell 7.6 will be our latest Long-Term Servicing (LTS) release.\nWe continue to align with the .NET 10 release cycle and support lifecycle.\nThere have already been 4 preview releases published.<\/p>\n This has been a long-standing request from the community due to automatic sync of MyDocuments folder and OneDrive.\nWhile some users want to leverage OneDrive for syncing across their systems,\nmany other users complain about the performance impact on PowerShell module discovery when modules are stored in the OneDrive folder.\nThere was a previous experimental feature PSModuleAutoLoadSkipOfflineFiles<\/a> that is now mainstream in PowerShell 7.5.\nWith this change, PowerShell skips modules that are not marked being available locally.\nHowever, this also led to confusion for users who expected their modules to be available when they were not on disk.<\/p>\n As any change here is a breaking change, we’ve spent a lot of time discussing the best way to approach this.\nWe are close to finishing a proposal that we will publish to the PowerShell-RFC<\/a> repository for\ncommunity feedback when ready.\nWe will have experimental feature available within the 7.6 preview cycle for users to test and provide feedback on.<\/p>\n Note that the PowerShell content folder does not just contain modules, but also the user’s PowerShell profile, scripts installed from PowerShell Gallery,\nand updated help files.<\/p>\n A common ask from several of our Microsoft partners who are building native commands (Azure CLI, Winget) is to more easily\nintegrate features such as Feedback Providers and Tab Completion where they don’t need to publish a separate module from their\napplication.<\/p>\n We have already published a design proposal in our RFC repo<\/a> and would welcome\nany feedback from the community.\nOne of the key requirements is that an application’s install and uninstall should be clean and not leave behind any artifacts in PowerShell.<\/p>\n Currently, if you use WinGet to install a package, it will not update the As part of our work to enable managing popular developer applications’ settings,\nwe are working on exposing Significant behind-the-scenes work is happening to migrate the PowerShell Gallery from an Azure Cloud Services classic application\nto one hosted on Azure Kubernetes Service (AKS).\nThis is a difficult effort but, ideally, one that won’t affect user access or performance.<\/p>\n Concurrently, we are working on support for EntraID authentication that\nallows users to use a managed identify to publish modules to the PowerShell Gallery instead of an API key.<\/p>\n Along with the changes necessary on the PowerShell Gallery side, corresponding changes are being made to PSResourceGet\nto support EntraID authentication.<\/p>\n We continue to progress towards General Availability for support of Microsoft Artifact Registry (MAR)<\/a> in PSResourceGet.\nThis allows users to have a default trusted repository for modules and scripts published by Microsoft.\nThis is built on top of the support we already added for Azure Container Registry (ACR)<\/a>\nOver time, we plan to generally support ORAS<\/a> as a standard for storing artifacts in container registries, which would enable\nsupport any container registry that supports the OCI distribution spec.<\/p>\n We continue to merge upstream OpenSSH changes into our Windows OpenSSH distribution with previews published to GitHub<\/a>\nand the final release updated into Windows.<\/p>\n We continue to develop a DSC v3 resource for We already announced DSC 3.0 General Availablity<\/a> last month and already have\ntwo service updates available.<\/p>\n DSC v3.0 is available in the Microsoft Store<\/a> or from our GitHub repo<\/a>.\nThe macOS and Linux releases are curently only available from our GitHub repo.<\/p>\n In addition, we are making rapid progress on a DSC v3.1 release with multiple previews<\/a> already available.\nPreview releases are also available from the Microsoft Store<\/a> or our GitHub repo.<\/p>\n You can see what features are approved<\/a> or\nbeing considered<\/a> for the 3.1 release.<\/p>\nPowerShell 7.6<\/h2>\n
Moving PowerShell content folder out of MyDocuments<\/h3>\n
Enable native commands to integrate with PowerShell more easily<\/h3>\n
Update
PATH<\/code> environment variable for WinGet<\/h3>\nPATH<\/code> environment variable.\nThis means that newly installed applications are not available in the current PowerShell session.\nThis feature will be similar to the one made in cmd.exe<\/code> and only apply to a specific applications.<\/p>\nPowerShell 7 configuration as DSC v3 resource<\/h3>\n
pwsh<\/code> as a DSC v3 resource.\nThis will allow users to manage the settings of PowerShell 7 in a declarative manner.<\/p>\nPowerShell Gallery<\/h2>\n
EntraID server-side support<\/h3>\n
PSResourceGet<\/h2>\n
EntraID client-side support<\/h3>\n
Complete Micorosft Artifact Registry (MAR) support<\/h3>\n
Windows OpenSSH<\/h2>\n
DSC v3 resource<\/h3>\n
SSHD_CONFIG<\/code> with expectations that previews will be available later this year.<\/p>\nDesired State Configuration v3 (DSC)<\/h2>\n
DSC v3.1<\/h3>\n
AI Shell<\/h2>\n