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

> PowerShell is a cross-platform shell, scripting language and cmdlet framework written in C#, MIT licensed and shipped on Windows, Linux and macOS. Two stable lines received patches on the same day in September 2026, changes here are never ported back to Windows PowerShell 5.1, and the container images on Microsoft's registry are declared unmaintained.

**PowerShell/PowerShell** — PowerShell is a cross-platform automation framework for Windows, Linux, and macOS, combining a shell and scripting language designed for structured data and REST APIs.

- Repository: https://github.com/PowerShell/PowerShell
- Website: https://microsoft.com/PowerShell
- Stars: 55,550 · Forks: 8,468
- Language: C#
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/powershell-powershell

## 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.6 and v7.5.11 were both published on 2026-09-08, three minutes apart, and v7.7.0-preview.5 followed on 2026-09-23. So there are two stable lines receiving patches at once and a third line in preview. 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 the documented way to end up with a broken or stale installation. 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. The same split applies to the documentation, which is why the learning material and the install guidance both point at Microsoft's documentation site rather than at this tree.

## Experimental features live in two JSON files, one per platform

At the repository root sit experimental-feature-linux.json and experimental-feature-windows.json, which is the clearest evidence that experimental status is tracked per operating system rather than per build. Anything you turn on from those files is, by definition, not covered by the compatibility promise, and the two files can diverge: a flag present on one platform may not exist on the other, so a script that depends on an experimental feature can work in your Linux CI and fail on a Windows workstation with no diagnostic beyond the missing flag. 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. Read the two experimental files before you pin a script to a feature that is not yet stable. The naming also tells you where to look when a behaviour differs between a developer's Linux box and a Windows CI runner, since the difference is encoded in a tracked file rather than in a compile time define you would have to go looking for.

## The images on Microsoft's registry are declared unmaintained

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. That is a distinction between the official project images and the registry path people have been pulling from for years, and it is the kind of tag that keeps working long after anyone stops publishing to it. 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. If your pipeline builds a base image from either path, that tag is a maintenance liability you own. Note that the unmaintained registry is a Microsoft registry rather than a community one, which is exactly why the announcement needed a callout rather than a commit note.

## 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 the documentation and TypeScript-adjacent files. 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:

```sh
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. That RFC route is the only way to change the language rather than patch it. One more piece of context sits at the root in the form of 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.

## 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-09-08 and the 7.7 line is still a preview. How you will update, because the README requires 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.

## FAQ

### What exactly does PowerShell do?

It is a cross-platform automation and configuration tool for Windows, Linux and macOS that works with existing tools. The README describes it as optimized for structured data such as JSON, CSV and XML, for REST APIs and for object models, and says it includes a command-line shell, an associated scripting language, and a framework for processing cmdlets.

### How do I install PowerShell 7?

The repository contains no install command. It states that PowerShell is supported on Windows, macOS and a variety of Linux platforms and links the installing page on Microsoft's documentation site. When you upgrade, use the same install method you used originally, because the update method differs for each platform and install method.

### How do I use PowerShell 7?

Issues in this repository are only for PowerShell 7.x and higher, and anything specific to Windows PowerShell 5.1 is reported through the Feedback Hub app instead. New users are pointed at the getting started documentation on Microsoft's documentation site, and design proposals go through the separate PowerShell-RFC repository.

### Is PowerShell easy to learn?

The repository does not make that claim either way. It points newcomers at a getting started path on Microsoft's documentation site, and for developers it points at a NuGet SDK package for .NET Core applications and at an RFC process for proposing design changes, which is where the learning curve for extending the language actually sits.

## Sources

- [Official documentation](https://microsoft.com/PowerShell)
- [Official README](https://github.com/PowerShell/PowerShell#readme)
- [Project repository](https://github.com/PowerShell/PowerShell)
- [Release notes](https://github.com/PowerShell/PowerShell/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/powershell-powershell