I would be surprised if you'll be able to hit that timeline unfortunately, we are still waiting on the rc1 release for 7.6 and unless the team decide on a very short churn I would be surprised if the rc and a final will be out within the next 3 weeks.

Thank you for the update and for providing clearer timelines for the PowerShell 7.6 release.

I understand and respect the quality-based release approach. However, from a support and product planning perspective, the lack of a predictable release cadence for PowerShell 7.x has become increasingly challenging. For vendors shipping products that support PowerShell, planning is already constrained by the relatively short .NET LTS lifecycle, which is outside the PowerShell teams control. Additional uncertainty around PowerShell release timing further complicates that planning.

Recent delays are also becoming a concern. PowerShell 7.5 was delayed, and 7.6 is now delayed by an additional two months. This raises questions about what prevents similar delays in future releases. Based on the current schedule, PowerShell 7.6 will be released roughly four months after the underlying .NET release, effectively reducing its supported lifetime from three years to approximately two years and eight months. While this may seem minor, three years is already a relatively short lifecycle compared to earlier PowerShell releases.

I fully appreciate that schedules can slip, but it would be helpful to see improvements in a few areas going forward:

• More clearly defined RC and GA timelines for each PowerShell release
• Closer alignment of those timelines with the corresponding .NET release
• Advance communication when timelines are at risk, including the reasons and updated expectations
• Consideration of a shorter RC period, such as two weeks, where feasible

The focus on quality is absolutely the right goal, but it should not preclude advance planning or transparent communication. This is especially important around year-end periods when public updates are typically limited. Greater predictability and visibility would significantly help the broader ecosystem that depends on PowerShell releases.

Agreed, I'm fully about quality driven, but the problem is that the support lifecycle is now "it depends". If the team were to offer an extended support period for the gap between the .NET such that it is always 3 years from the date of release for example. Probably not feasible but let's say this gets to a ridiculous level and PowerShell releases start lagging 1 year behind, now it's the same amount of support as an STS.

It's not a video game, so "when its done" is a little difficult for business predictability.

February 17, 2026 was yesterday.

February 17, 2026 was yesterday.

It's out now (~4 hoirs ago) https://github.com/PowerShell/PowerShell/releases/tag/v7.6.0-rc.1
Sad to see no one from the PowerShell team taking the time to keep us updated here...

They are 2 different products 🤷🤷🤷

.NET support lifecycle is 3 years for LTS releases, that means after 3 years its unsupported. PowerShell is built on .NET and follows the .NET support lifecycle as stated. That means if a LTS release does not come out at the same time, you do not get the full lifecycle of support. If it were 10 years like Windows, that's less of a big deal, but losing 15% of your support lifecycle is a big deal. It also shortens the timeframe you have to migrate from PS7.4 until it goes out of support in November, cutting that migration window by 25% already (and who knows how much longer) is also a BIG deal, especially to downstream products like Azure Functions and Automation, who already had a hard enough time and ran out-of-support versions for quite a while before getting up to snuff.

Further, if you are staying with .NET lifecycles, if you have a dependency on PowerShell as @mamoreau-devolutions does, you have to hold back your entire upgrade until it caches up.

We are talking enterprise needs, not hobby level support. If the PowerShell team adopted their support lifecycle as 3 years after release, and not pinned to .NET, that'd be an acceptable answer, but there'd be a gap where the PowerShell team would be responsible if say, a major security vulnerability appeared in the underlying .NET version in that timeframe where they are still supporting it. Hence the problem.

If PowerShell support was not pinned to the .NET support, then you'd be correct, no need to force it, but it IS pinned to .NET support and not having a release creates headaches.

What Justin said, and what I said previously. If you look at PowerShell only from the point of view of capabilities provided by the core PowerShell cmdlets, you may wonder why it is worth following the .NET runtime release cadence, and think this is just "upgrading for the sake of upgrading".

Large .NET shops like Devolutions have to cover a wide variety of target platforms which includes PowerShell. We have a massive C# code base for all of our products, and our PowerShell module is built on top of the same core as Remote Desktop Manager. This means that coordinating a .NET runtime switch is easier done for all platforms around the same time, instead of using inconsistent versions based on the platform, with features and fixes that may be available on one platform but not the other.

Let me give an example we've hit when migrating from .NET 8 to .NET 9: as odd as it seems, we support connecting to SQL Server from Android. We've hit a really nasty bug in the .NET runtime that killed the connection when SQL queries were larger than a specified length. After thorough investigation, I diagnosed the problem: a hardcoded number of bytes used for TLS fragmentation, causing a protocol violation in MS-TDS.

What does Android even have to do with PowerShell? Directly, nothing. Indirectly: we're building everything from the same code base, so that shared dependency that goes into that PowerShell module is also built for Android, with various features turned on or off. That particular fix was never backported to .NET 8, so in order to get the problem fixed for Android, we were eagerly waiting for .NET 9 to come out. I recall that when we switched to .NET 9, PowerShell 7.5 had barely just come out with a stable release (it was already lagging behind).

If you look at the problem only with PowerShell lenses, you'd think it's not a big deal. If you look at it from the .NET ecosystem perspective, you can realize how PowerShell holding us back on .NET runtime upgrades has costly side effects for vendors that use .NET everywhere, not just PowerShell.

We've moved away from .NET Framework years ago, and we're now trying to keep up with the .NET runtime release cadence, to benefit from the latest improvements (features, performances, but also bug fixes). We've been able to target a single .NET runtime at once for all platforms at once for many years, something which was very hard to achieve.

Now you can imagine why I'm not happy to have to explain to colleagues why we can't migrate everything to .NET 10 because there's no stable release of PowerShell yet based on it. Not only it doesn't look good, but it creates more work for us internally, and it sends a signal that something's wrong with PowerShell.

Understood. But you're complaining about being behind by months. Not years.

And enterprises have the ability to force upgrades at their own cadence, within hours, days or weeks of releases if they desire. It's a solved problem.

As you pointed out hobbyists are at the whim of their own upgrade cycles, and probably less likely to be affected.

.NET 9 is a short-term support release, so a 4-5 month delay from PowerShell to migrate to .NET 10 is a big deal. Don't forget we need to give enough time for users to upgrade PowerShell, and that .NET runtime upgrades are not something you push in a minor product release, so for us, this gives us 3 opportunities per year to make such a major change. This is something that has to be coordinated and communicated well to our own customers so they can prepare accordingly.

Out now https://github.com/PowerShell/PowerShell/releases/tag/v7.6.0-rc.1