PowerShell: two patched stable lines, and container images nobody maintains

Two stable lines were patched on the same afternoon

The release list is the first thing to read, because it tells you how many lines you are choosing between. v7.6.9 and v7.5.13 were both published on 2026-10-25, four minutes apart, and v7.7.0-rc.1 followed on 2026-10-29. So there are two stable lines receiving patches at once and a third line in pre-release. That is a normal arrangement for a project with a broad user base, and it means the version you install is a support decision, not just a features decision. The upgrade instruction that comes with it is the one people get wrong: use the same install method you used when you first installed, because the update method is different for each platform and each install method. Mixing them, installing with one mechanism and trying to update with another, is what the README's advice to use the same install method is meant to avoid. Two stable lines and a preview also means three different answers to the question of what is currently supported, and the preview tag is the one that will look newest in any list you search.

Nothing fixed here is ported back to Windows PowerShell 5.1

The README states the relationship in one paragraph and it has real consequences. This repository started as a fork of the Windows PowerShell codebase, changes made here are not ported back to Windows PowerShell 5.1, and the issues tracked here are only for PowerShell 7.x and higher. Anything specific to Windows PowerShell is supposed to go through the Feedback Hub app instead, choosing Apps and then PowerShell in the category. So there are two products with two issue trackers, and they diverge over time rather than converging. For a team with mixed estate that is the thing to plan around: a bug you reproduce on 7.x and file here will not be fixed on 5.1, and a 5.1 bug reported through Feedback Hub will not be fixed here.

Experimental features live in two JSON files, one per platform

At the repository root sit experimental-feature-linux.json and experimental-feature-windows.json, one for each platform. The same root also holds global.json, DotnetRuntimeMetadata.json and .globalconfig for the toolchain, and es-metadata.yml, plus Localize/ for translations and dsc/ for the Desired State Configuration material.

Check the maintenance status of each container image

The Docker section carries a callout that deserves to be quoted rather than paraphrased. The PowerShell container images are now maintained by the .NET team, and the containers at mcr.microsoft.com/powershell are currently not maintained. There is a second licensing wrinkle in the same section: requesting and using the Container OS Image for Windows containers means accepting Supplemental License Terms held in the Microsoft Artifact Registry, so a Windows container is not covered by the project's MIT licence in the way the source is. Microsoft documents .NET SDK images with PowerShell preinstalled. Check the maintenance and support status of the specific image and tag used by your pipeline.

The build system is itself a PowerShell module

Building the tool requires bootstrapping with the tool, which is visible in the root. build.psm1 is a PowerShell module rather than a shell script, sitting next to PowerShell.sln, PowerShell.Common.props, Analyzers.props, stylecop.json, Settings.StyleCop and codecov.yml. Then there is the .NET side: global.json, DotnetRuntimeMetadata.json, nuget.config and .globalconfig for analyser and formatting defaults, plus .editorconfig, .prettierrc and .markdownlint.json for editor and documentation formatting. The pipeline definitions live in .pipelines/ and .vsts-ci/, and there is a .devcontainer/ for a containerised development environment. Getting the source is the one command the README gives:

git clone https://github.com/PowerShell/PowerShell.git

Build instructions are split by platform into docs/building/linux.md, docs/building/windows-core.md and docs/building/macos.md, with a developer FAQ at docs/FAQ.md for anything that goes wrong.

Discussions is labelled an experiment, with expectations written down

The community section is unusually candid about what maintainers will and will not do. GitHub Discussions is described as a feature for topics that are not related to code, unlike issues, and as an experiment the repositories are running to see whether it moves non-code conversation out of issues so that issues stay actionable. The README then says there should be no expectation that PowerShell team members are regular participants, that individual members may choose to take part, and that the expectation is that community members help drive the discussions. Read that as a service level agreement with the value written on it. A question that sits in Discussions can go unanswered by the project, while an issue is where the team commits to being actionable. The chat channels follow the same pattern, with Discord, IRC on Libera.Chat and Slack described as community-driven on a PowerShell Virtual User Group.

Telemetry and governance are documented, the install command is not

What this repository does not contain is an install command. The Get PowerShell section states that PowerShell is supported on Windows, macOS and a variety of Linux platforms and links the installing page on Microsoft's documentation site, which is where the actual package names and download steps live. So the repository is the source and the design record, not the installer. The documentation that does live here is worth knowing about. There is a telemetry topic documenting what PowerShell gathers, a governance policy at docs/community/governance.md, a code of conduct, a security policy under .github/, and a support section. For developers there is a NuGet SDK package for .NET Core applications targeting PowerShell Core, documented in the FAQ, and a separate repository for request for comments where proposed design changes are argued over before they are written. One more piece of context in the README is a community dashboard built with PowerShell, Azure and Power BI, published through an aka.ms link with a blog post explaining the reasoning, which tells you the project measures its own contribution activity and shares the numbers.

Editorial conclusion

Adopt PowerShell 7 when you administer Windows and Linux from the same script, or when you want a shell that passes objects and handles JSON, CSV and XML natively instead of parsing text. Stay on Windows PowerShell 5.1 if you are bound to it, and do not expect a fix reported here to arrive there. Verify four things before you standardise on it. Which line you install, since two stable versions were patched on 2026-10-25 and the 7.7 line is still at a release candidate. How you will update, because the README advises you to keep the install method you first used, as the update path differs per platform. Where your container images come from, since the tags on Microsoft's registry are described as not maintained while the .NET team maintains the official ones. And what telemetry your environment sends, since a dedicated topic documents it.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes