PowerShell 7: The Cross-Platform Shell That Split From Windows PowerShell

What This Repository Actually Is

This is the source repository for PowerShell 7 and higher, not for Windows PowerShell 5.1. The README is explicit: the repository started as a fork of the Windows PowerShell codebase, but changes made here are not ported back to 5.1. That distinction matters for anyone evaluating the project. If you file an issue here, it applies only to PowerShell 7.x and above. Windows PowerShell issues must go through the Feedback Hub app. The project describes itself as a cross-platform automation and configuration tool for Windows, Linux, and macOS, optimized for structured data like JSON, CSV, and XML, and for REST APIs and object models. It is a command-line shell, a scripting language, and a cmdlet processing framework in one. For engineers, the practical takeaway is that this is not an upgrade path from 5.1; it is a separate product with its own lifecycle.

The Mechanism: Objects, Not Text

The core design is that PowerShell passes objects between commands, not plain text. The README emphasizes that the tool is optimized for structured data and object models. That means a pipeline carries typed data, so you can access properties directly instead of parsing strings. For example, a command that returns process objects lets you filter on CPU usage without regex. This is the fundamental difference from traditional Unix shells, which pass strings. The framework for processing cmdlets is part of the same codebase, so writing a cmdlet in C# and shipping it as a module is a first-class path. The repository includes a PowerShell SDK NuGet package for .NET Core C# applications, which the FAQ mentions. That SDK is how you embed PowerShell into your own tools. The mechanism is not new, but it is consistent: object-oriented pipelines, a scripting language on top, and a cmdlet framework underneath.

Building and Running From Source

The repository gives concrete build instructions for Linux, Windows, and macOS, each in separate docs files. The first step is cloning: git clone https://github.com/PowerShell/PowerShell.git. After that, you follow the platform-specific guide under docs/building/. The README warns that if you hit build problems, you should consult the developer FAQ before filing an issue. There is also a contribution guide and a PowerShell-RFC repository for design proposals. For installation, the README points to the official Installing PowerShell documentation, which covers all supported platforms. The upgrade advice is specific: use the same install method you used originally, because the update path differs by platform and method. That is a practical constraint that many users overlook. If you installed via a package manager, upgrade via that same manager, not by downloading a tarball.

The Container Catch: Images Are Not Maintained Here

One of the most striking details in the README is the container notice. It states, with an Important tag, that the PowerShell container images are now maintained by the .NET team, and that the containers at mcr.microsoft.com/powershell are currently not maintained. That is a real failure mode for anyone who assumes the official PowerShell repo publishes its own images. If you pull from that registry, you are getting an unmaintained image. The README also notes that using Windows container OS images requires accepting the Supplemental License Terms on the Microsoft Artifact Registry. For an engineer evaluating this project, this means container-based deployments need extra verification. You must check the current .NET team's images, confirm their tag conventions, and test your scripts against those images. The repository itself does not provide a Dockerfile in the README, so you cannot assume a build-from-source container path.

Telemetry and Governance: What You Agree To

The project collects telemetry, and the README points to the about_Telemetry topic for details. That is a genuine consideration for adoption, especially in regulated or air-gapped environments. You should read that documentation before deploying, because telemetry can affect privacy and compliance. The governance policy is documented in the repo, so there is a defined process for how decisions are made. The README also describes GitHub Discussions as an experiment, with no expectation that team members participate regularly. That is a limitation for community support: you cannot rely on maintainers answering discussion posts. Issues are the actionable channel, but even there, the README says the team or community members keep issues actionable. For a tool this widely used, the governance structure is relatively transparent, but the telemetry is a default you must explicitly evaluate. The license is MIT, which is permissive, but the container images have separate license terms.

The Real Alternative: Windows PowerShell 5.1

The direct alternative is not another shell like bash; it is Windows PowerShell 5.1, the predecessor. The difference is not just version number. PowerShell 5.1 is Windows-only, built on .NET Framework, and receives fixes through Windows updates. PowerShell 7 is cross-platform, built on .NET (Core), and ships on its own release cadence as shown by the recent releases: v7.6.5, v7.5.10, and v7.4.19 all came out on the same day. That means multiple versions are supported simultaneously, which is a maintenance burden. Modules written for 5.1 may not work in 7.x because the underlying .NET runtime changed. The README is clear that changes in this repository do not flow back to 5.1. So if you have a large investment in 5.1 modules, you have a migration project, not an upgrade. For new work, 7.x is the obvious choice, but for existing Windows automation, 5.1 remains a valid, supported option.

Release Cadence and Support Realities

The release history shows a pattern: v7.6.5, v7.5.10, and v7.4.19 were all pushed on the same date in August 2026. That means three minor versions are getting patches at the same time. For an enterprise, that is a signal that you must track which version you are on and which is supported. The README does not state a support policy, but the existence of three active release lines suggests a long-term servicing approach. The project is not archived, and the last push is the same date as those releases, so development is active. However, the README's support section points to a separate SUPPORT.md file, which you should read before relying on community help. The cadence also means upgrading is a recurring task, and the README's advice to use the same install method is the only concrete guidance. You should plan for regular version checks, not a one-time install.

Editorial conclusion

Adopt PowerShell 7 if you need a cross-platform shell that handles structured data and REST APIs, and if you are comfortable with a fast release cadence (v7.4, v7.5, v7.6 all active). Do not adopt it if you rely on Windows PowerShell 5.1 modules or expect changes to flow back from this repository to 5.1; they do not. Before adopting, verify that your existing scripts and modules work under 7.x, check the telemetry defaults in about_Telemetry, and confirm which support channel (community vs. Microsoft) matches your needs. The container images at mcr.microsoft.com/powershell are explicitly not maintained, so if you plan to use containers, verify the current .NET team's images instead.

Official sources

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