We’re proud to announce the general availability of PowerShell 7.3!
PowerShell 7.3 is built on top of .NET 7 and as a non-LTS (Long Term Support) release will be supported for 18 months.
PowerShell 7.2 is still the current LTS (3-year supported) release of PowerShell.
How do I get it?
Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a variety of ways to get it.
If you had installed the previous PowerShell 7 stable release (7.2) via the Windows Store,
you will be automatically updated to 7.3 GA.
However, if you installed the MSI and chose to be updated via Microsoft Update, since 7.2 is a LTS release,
you will not be automatically upgraded to 7.3 and needs to be manually installed.
You can see a video of demos I presented at this year’s PSConfEU minicon.
It covers some of the major changes including new features and important bug fixes.
Lots of the work presented were contributions fromm the community!
We found a last minute issue that should not affect most users that we will fix in an expected 7.3.1 release in December.
Due to an issue with our framework dependent package to be included with the .NET SDK Docker images,
the .NET 7 GA SDK image will still have PowerShell 7.3-rc.1 included.
This should not have any functional impact to users and we expect to update the image with PowerShell 7.3 GA in December.
Focus on the shell
The major theme for this release is focusing on making PowerShell 7 a great shell environment.
Here, “native command” means an executable that is not a PowerShell cmdlet or function.
Improvement to native command argument passing
Windows and Linux/macOS have fundamental differences in how native command arguments are handled specifically when quotes are involved.
We added a new feature
to control how PowerShell passes arguments to native commands.
The default behavior for Windows and Linux/macOS should work as most users expect in their respective environments.
Another area to make native commands work more like cmdlets is error handling.
Unlike cmdlets, native commands use their exit code to convey success or failure.
Consistency in error handling for native commands
stderr is often used for error messages,
it is also used for progress, information, warnings, etc. because native commands don’t have the rich streams that PowerShell cmdlets have.
Although a non-zero exit code does NOT always indicate an error, the convention for native commands is that a non-zero exit code typically indicates an error.
A new feature
allows you to have PowerShell treat a non-zero exit code as an error.
This means that you can set
Stop and have PowerShell stop execution whether a cmdlet had an error or a native command had a non-zero exit code.
This simplifies scripts that previously would have to check
after execution of a native command or wrap it in a helper function.
PowerShell 7.4 will be our next LTS release and expected to be built on .NET 8 for next year.
We’ll have a separate blog post early next year to discuss the investments of the PowerShell/OpenSSH team for 2023.
We appreciate all the efforts of the community, both individuals and working group members,
and look forward to your continued feedback and contributions!