{"id":20938,"date":"2026-04-01T13:01:54","date_gmt":"2026-04-01T21:01:54","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=20938"},"modified":"2026-04-01T14:58:43","modified_gmt":"2026-04-01T22:58:43","slug":"powershell-7-6-release-postmortem","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershell-7-6-release-postmortem\/","title":{"rendered":"PowerShell 7.6 release postmortem and investments"},"content":{"rendered":"<p><!-- markdownlint-disable MD041 --><\/p>\n<p>We recently released PowerShell 7.6, and we want to take a moment to share context on the delayed\ntiming of this release, what we learned, and what we&#8217;re already changing as a result.<\/p>\n<p>PowerShell releases typically align closely with the .NET release schedule. Our goal is to provide\npredictable and timely releases for our users. For 7.6, we planned to release earlier in the cycle,\nbut ultimately shipped in March 2026.<\/p>\n<h2>What goes into a PowerShell release<\/h2>\n<p>Building and testing a PowerShell release is a complex process with many moving parts:<\/p>\n<ul>\n<li>3 to 4 release versions of PowerShell each month (e.g. 7.4.14, 7.5.5, 7.6.0)<\/li>\n<li>29 packages in 8 package formats<\/li>\n<li>4 architectures (x64, Arm64, x86, Arm32)<\/li>\n<li>8 operating systems (multiple versions each)<\/li>\n<li>Published to 4 repositories (GitHub, PMC, winget, Microsoft Store) plus a PR to the .NET SDK image<\/li>\n<li>287,855 total tests run across all platforms and packages per release<\/li>\n<\/ul>\n<h2>What happened<\/h2>\n<p>The PowerShell 7.6 release was delayed beyond its original target and ultimately shipped in March\n2026.<\/p>\n<p>During the release cycle, we encountered a set of issues that affected packaging, validation, and\nrelease coordination. These issues emerged late in the cycle and reduced our ability to validate\nchanges and maintain release cadence.<\/p>\n<p>Combined with the standard December release pause, these factors extended the overall release\ntimeline.<\/p>\n<h2>Timeline<\/h2>\n<ul>\n<li><strong>October 2025<\/strong> &#8211; Packaging-related changes were introduced as part of ongoing work for the 7.6\nrelease.<\/p>\n<ul>\n<li>Changes to the build created a bug in 7.6-preview.5 that caused the Alpine package to fail. The\nmethod used in the new build system to build the Microsoft.PowerShell.Native library wasn&#8217;t\ncompatible with Alpine. This required additional changes for the Alpine build.<\/li>\n<\/ul>\n<\/li>\n<li><strong>November 2025<\/strong> &#8211; Additional compliance requirements were imposed requiring changes to packaging\ntooling for non-Windows platforms.<\/p>\n<ul>\n<li>Because of the additional work created by these requirements, we weren&#8217;t able to ship the fixes\nmade in October until December.<\/li>\n<\/ul>\n<\/li>\n<li><strong>December 2025<\/strong> &#8211; We shipped 7.6-preview.6, but due to the holidays there were complications\ncaused by a change freeze and limited availability of key personnel.<\/p>\n<ul>\n<li>We weren&#8217;t able to publish to PMC during our holiday freeze window.<\/li>\n<li>We couldn&#8217;t publish NuGet packages because the current manual process limits who can perform the\ntask.<\/li>\n<\/ul>\n<\/li>\n<li><strong>January 2026<\/strong> &#8211; Packaging changes required deeper rework than initially expected and validation\nissues began surfacing across platforms.<\/p>\n<ul>\n<li>We also discovered a compatibility issue in RHEL 8. The libpsl-native library must be built to\nsupport glibc 2.28 rather than glibc 2.33 used by RHEL 9 and higher.<\/li>\n<\/ul>\n<\/li>\n<li><strong>February 2026<\/strong> &#8211; Ongoing fixes, validation, and backporting of packaging changes across release\nbranches continued.<\/li>\n<li><strong>March 2026<\/strong> &#8211; Packaging changes stabilized, validation completed, and PowerShell 7.6 was\nreleased.<\/li>\n<\/ul>\n<h2>What went wrong and why<\/h2>\n<p>Several factors contributed to the delay beyond the initial packaging change.<\/p>\n<ul>\n<li><strong><strong>Late-cycle packaging system changes<\/strong><\/strong>\nA 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\nfull 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.<\/li>\n<li><strong><strong>Tight coupling to packaging dependencies<\/strong><\/strong>\nOur 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.<\/li>\n<li><strong><strong>Reduced validation signal from previews<\/strong><\/strong>\nOur 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.<\/li>\n<li><strong><strong>Branching and backport complexity<\/strong><\/strong>\nBecause 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.<\/li>\n<li><strong><strong>Release ownership and coordination gaps<\/strong><\/strong>\nRelease 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.<\/li>\n<li><strong><strong>Lack of early risk signals<\/strong><\/strong>\nWe 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.<\/li>\n<\/ul>\n<h2>How we responded<\/h2>\n<p>As the scope of the issue became clear, we shifted from attempting incremental fixes to stabilizing\nthe packaging system as a prerequisite for release.<\/p>\n<ul>\n<li>We evaluated patching the existing packaging workflow versus replacing it, and determined a full\nreplacement was required to meet compliance requirements.<\/li>\n<li>We rebuilt the packaging workflows for non-Windows platforms, including RPM, DEB, and PKG formats.<\/li>\n<li>We validated the new packaging system across all supported architectures and operating systems to\nensure correctness and consistency.<\/li>\n<li>We backported the updated packaging logic across active release branches to maintain alignment\nbetween versions.<\/li>\n<li>We coordinated across maintainers to prioritize stabilization work over continuing release\nprogression with incomplete validation.<\/li>\n<\/ul>\n<p>This shift ensured a stable and compliant release, but extended the overall timeline as we\nprioritized correctness and cross-platform consistency over release speed.<\/p>\n<h2>Detection gap<\/h2>\n<p>A key gap during this release cycle was the lack of early signals indicating that the packaging\nchanges would significantly impact the release timeline.<\/p>\n<p>Reduced preview cadence and late-cycle changes limited our ability to detect issues early.\nAdditionally, the absence of clear release ownership and structured tracking made it more difficult\nto identify and communicate risk as it developed.<\/p>\n<h2>What we are doing to improve<\/h2>\n<p>This experience highlighted several areas where we can improve how we deliver releases. We&#8217;ve\nalready begun implementing changes:<\/p>\n<ul>\n<li><strong><strong>Clear release ownership<\/strong><\/strong>\nWe have established explicit ownership for each release, with clear responsibility and transfer mechanisms between maintainers.<\/li>\n<li><strong><strong>Improved release tracking<\/strong><\/strong>\nWe are using internal tracking systems to make release status and blockers more visible across the team.<\/li>\n<li><strong><strong>Consistent preview cadence<\/strong><\/strong>\nWe are reinforcing a regular preview schedule to surface issues earlier in the cycle.<\/li>\n<li><strong><strong>Reduced packaging complexity<\/strong><\/strong>\nWe are working to simplify and consolidate packaging systems to make future updates more predictable.<\/li>\n<li><strong><strong>Improved automation<\/strong><\/strong>\nWe are exploring additional automation to reduce manual steps and improve reliability in the face of changing requirements.<\/li>\n<li><strong><strong>Better communication signals<\/strong><\/strong>\nWe 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 <a href=\"https:\/\/github.com\/PowerShell\/PowerShell\/discussions\">discussions<\/a>.<\/li>\n<\/ul>\n<h2>Moving forward<\/h2>\n<p>We understand that many of you rely on PowerShell releases to align with your own planning and\nvalidation cycles. Improving release predictability and transparency is a priority for the team, and\nthese changes are already in progress.<\/p>\n<p>We appreciate the feedback and patience we received from the community as we worked through these\nchanges, and we&#8217;re committed to continuing to improve how we deliver PowerShell.<\/p>\n<p>\u2014 The PowerShell Team<\/p>\n<p><!-- link references --><\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post shares context on the delayed timing of the PowerShell 7.6 release, our learnings, and the changes the team has already begun making to improve release predictability and transparency.<\/p>\n","protected":false},"author":7527,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[266],"class_list":["post-20938","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-powershell-release"],"acf":[],"blog_post_summary":"<p>This post shares context on the delayed timing of the PowerShell 7.6 release, our learnings, and the changes the team has already begun making to improve release predictability and transparency.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20938","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/7527"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=20938"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20938\/revisions"}],"predecessor-version":[{"id":20946,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/20938\/revisions\/20946"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=20938"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=20938"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=20938"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}