We recently released PowerShell 7.6, and we want to take a moment to share context on the delayed
timing of this release, what we learned, and what we’re already changing as a result.
PowerShell releases typically align closely with the .NET release schedule. Our goal is to provide
predictable and timely releases for our users. For 7.6, we planned to release earlier in the cycle,
but ultimately shipped in March 2026.
What goes into a PowerShell release
Building and testing a PowerShell release is a complex process with many moving parts:
- 3 to 4 release versions of PowerShell each month (e.g. 7.4.14, 7.5.5, 7.6.0)
- 29 packages in 8 package formats
- 4 architectures (x64, Arm64, x86, Arm32)
- 8 operating systems (multiple versions each)
- Published to 4 repositories (GitHub, PMC, winget, Microsoft Store) plus a PR to the .NET SDK image
- 287,855 total tests run across all platforms and packages per release
What happened
The PowerShell 7.6 release was delayed beyond its original target and ultimately shipped in March
2026.
During the release cycle, we encountered a set of issues that affected packaging, validation, and
release coordination. These issues emerged late in the cycle and reduced our ability to validate
changes and maintain release cadence.
Combined with the standard December release pause, these factors extended the overall release
timeline.
Timeline
- October 2025 – Packaging-related changes were introduced as part of ongoing work for the 7.6
release.- Changes to the build created a bug in 7.6-preview.5 that caused the Alpine package to fail. The
method used in the new build system to build the Microsoft.PowerShell.Native library wasn’t
compatible with Alpine. This required additional changes for the Alpine build.
- Changes to the build created a bug in 7.6-preview.5 that caused the Alpine package to fail. The
- November 2025 – Additional compliance requirements were imposed requiring changes to packaging
tooling for non-Windows platforms.- Because of the additional work created by these requirements, we weren’t able to ship the fixes
made in October until December.
- Because of the additional work created by these requirements, we weren’t able to ship the fixes
- December 2025 – We shipped 7.6-preview.6, but due to the holidays there were complications
caused by a change freeze and limited availability of key personnel.- We weren’t able to publish to PMC during the holiday freeze.
- We couldn’t publish NuGet packages because the current manual process limits who can perform the
task.
- January 2026 – Packaging changes required deeper rework than initially expected and validation
issues began surfacing across platforms.- We also discovered a compatibility issue in RHEL 8. The libpsl-native library must be built to
support glibc 2.28 rather than glibc 2.33 used by RHEL 9 and higher.
- We also discovered a compatibility issue in RHEL 8. The libpsl-native library must be built to
- February 2026 – Ongoing fixes, validation, and backporting of packaging changes across release
branches continued. - March 2026 – Packaging changes stabilized, validation completed, and PowerShell 7.6 was
released.
What went wrong and why
Several factors contributed to the delay beyond the initial packaging change.
- Late-cycle packaging system changes
A compliance requirement required us to replace the tooling used to generate non-Windows packages (RPM, DEB, PKG). We evaluated whether this could be addressed with incremental changes, but determined that the existing tooling could not be adapted to meet requirements. This required a
full replacement of the packaging workflow.Because this change occurred late in the release cycle, we had limited time to validate the new system across all supported platforms and architectures. - Tight coupling to packaging dependencies
Our release pipeline relied on this tooling as a critical dependency. When it became unavailable, we did not have an alternate implementation ready. This forced us to create a replacement for a core part of the release pipeline, from scratch, under time pressure, increasing both risk and complexity. - Reduced validation signal from previews
Our preview cadence slowed during this period, which reduced opportunities to validate changes incrementally. As a result, issues introduced by the packaging changes were discovered later in the cycle, when changes were more expensive to correct. - Branching and backport complexity
Because of new compliance requirements, changes needed to be backported and validated across multiple active branches. This increased the coordination overhead and extended the time required to reach a stable state. - Release ownership and coordination gaps
Release ownership was not explicitly defined, particularly during maintainer handoffs. This made it difficult to track progress, assign responsibility for blockers, and make timely decisions during critical phases of the release. - Lack of early risk signals
We did not have clear signals indicating that the release timeline was at risk. Without structured tracking of release health and ownership, issues accumulated without triggering early escalation or communication.
How we responded
As the scope of the issue became clear, we shifted from attempting incremental fixes to stabilizing
the packaging system as a prerequisite for release.
- We evaluated patching the existing packaging workflow versus replacing it, and determined a full
replacement was required to meet compliance requirements. - We rebuilt the packaging workflows for non-Windows platforms, including RPM, DEB, and PKG formats.
- We validated the new packaging system across all supported architectures and operating systems to
ensure correctness and consistency. - We backported the updated packaging logic across active release branches to maintain alignment
between versions. - We coordinated across maintainers to prioritize stabilization work over continuing release
progression with incomplete validation.
This shift ensured a stable and compliant release, but extended the overall timeline as we
prioritized correctness and cross-platform consistency over release speed.
Detection gap
A key gap during this release cycle was the lack of early signals indicating that the packaging
changes would significantly impact the release timeline.
Reduced preview cadence and late-cycle changes limited our ability to detect issues early.
Additionally, the absence of clear release ownership and structured tracking made it more difficult
to identify and communicate risk as it developed.
What we are doing to improve
This experience highlighted several areas where we can improve how we deliver releases. We’ve
already begun implementing changes:
- Clear release ownership
We have established explicit ownership for each release, with clear responsibility and transfer mechanisms between maintainers. - Improved release tracking
We are using internal tracking systems to make release status and blockers more visible across the team. - Consistent preview cadence
We are reinforcing a regular preview schedule to surface issues earlier in the cycle. - Reduced packaging complexity
We are working to simplify and consolidate packaging systems to make future updates more predictable. - Improved automation
We are exploring additional automation to reduce manual steps and improve reliability in the face of changing requirements. - Better communication signals
We are identifying clearer signals in the release process to notify the community earlier when timelines are at risk. Going forward, we will share updates through the PowerShell repository discussions.
Moving forward
We understand that many of you rely on PowerShell releases to align with your own planning and
validation cycles. Improving release predictability and transparency is a priority for the team, and
these changes are already in progress.
We appreciate the feedback and patience we received from the community as we worked through these
changes, and we’re committed to continuing to improve how we deliver PowerShell.
— The PowerShell Team
The post PowerShell 7.6 release postmortem and investments appeared first on PowerShell Team.
By removing the ADS, the malicious script makes the file look less suspicious if the system is scanned to search for "downloaded" files (a classic operation performed in DFIR investigations).










