Fans of PowerShell were frustrated and confused by the delayed release of the most recent Long Term Support edition. PowerShell 7.6 LTS was only released recently, but it came significantly later than had been planned.
Unpicking what happened, Microsoft has provided some details about why there was a delay. The company has conducted what it refers to as a postmortem into the slowed schedule and says that it is making changes as a result.
Pointing to the fact that PowerShell is a complicated beast, senior product manager Jason Helmick starts off an explanatory blog post by saying: “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”.
Going on to explain what caused the delay, he continues:
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.
Problems with the development of the build proved to be more complex than expected leading to severe hold-ups:
- 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.
Microsoft is aware that there are large numbers of users who rely on the predictability of release dates. As such, the company has implemented – and continues to implement – a number of 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.
