Should PowerShell 7.x ship inbox in Windows? #24340
Replies: 75 comments 125 replies
-
|
Yes. I write modules that are useful for PC enthusiasts who don't necessarily use PowerShell in their daily lives. It would add unnecessary friction to the user experience if these people had to go out of their way to install PowerShell before using my modules, so I stick to Windows PowerShell features in scripts and .NET standard 2.0 in binary modules. This means I'm essentially stuck in the year 2016 in terms of language features. This might not be so bad in 2024, but what about in 2034 or 2044? In the IT enterprise world it's a similar story where a consultant may want to write some automation tool but because they can't be certain than there's anything higher than PS 5.1 installed in the environment they may opt to use a different tool than PowerShell. |
Beta Was this translation helpful? Give feedback.
-
|
I support the point. PowerShell 7+ makes the difference. Luckily, I have an option to install PowerShell 7+ on my machines; alas, a lot of other people don't, so making it inbox would help those. |
Beta Was this translation helpful? Give feedback.
-
|
I think we should ask ourselves the opposite question. Is there are good reason to NOT ship it? Everything as far as I'm aware is backward compatible so there isn't a good reason to not ship it. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly! |
Beta Was this translation helpful? Give feedback.
-
|
Indeed! |
Beta Was this translation helpful? Give feedback.
-
|
Indeed! |
Beta Was this translation helpful? Give feedback.
-
it isnt |
Beta Was this translation helpful? Give feedback.
-
|
@BlackV even in those cases where the two are not compatible, similarly if shipped with the OS then presumably there would be a period where the two are installed side-by-side. The user could and should explicitly call out which version either |
Beta Was this translation helpful? Give feedback.
-
|
I've been wondering why it hasn't yet. |
Beta Was this translation helpful? Give feedback.
-
|
PowerShell Core is built on top of .NET Core. And the latter isn't shipped with Windows as well, to avoid the need to support the Windows version as long as that version of Windows 10 is supported. In other words, to separate the lifecycle of the two products. See https://www.reddit.com/r/dotnet/comments/fc0g0k/why_is_net_core_not_distributed_automatically/ |
Beta Was this translation helpful? Give feedback.
-
|
This would allow me to develop all of my powershell for powershell 7 across my enterprise without having to worry about installing it on every device across the enterprise. Updates could take place via windows update. Would be so nice. It seems kind of common sense to include it in the OS despite whatever the challenges are. Also, the security benefits of being able to use SSH authentication across the board for all remote powershell authentication would be SO nice. |
Beta Was this translation helpful? Give feedback.
-
|
To better support enterprise life-cycles and stability, an included version could even be set to follow the LTS release cycle via Windows Update. |
Beta Was this translation helpful? Give feedback.
-
but SSH is something you'd have to enable/install and configure on each of those systems as well |
Beta Was this translation helpful? Give feedback.
-
It wouldn't. |
Beta Was this translation helpful? Give feedback.
-
So much this. I can't imagine the ldap, adsi, and other underpinnings are that complicated to port AD cmdlets. This seems so lame claiming Microsoft can't figure out how to code their own tech. Instead we get garbage like WAC which is broken from inception, instead of fast functional componentry without 10 layers of indirection from win32. |
Beta Was this translation helpful? Give feedback.
-
|
Yes please 🥺 |
Beta Was this translation helpful? Give feedback.
-
|
One of the biggest hurdles with Powershell is the difficulty in parallel execution. I have done it, but it is nowhere as simple as with Powershell 7. I think this would be an improvement in regard to convenience. I would also point out that the attitude towards Powershell in the DevOps space seems to have shifted quite drastically since the port to Linux. If we had native support for simple parallel execution, it would be that much more of a no-brainer for DevOps folks versus, say, Python. |
Beta Was this translation helpful? Give feedback.
-
|
And, this probably goes without saying, but increased adoption amongst the DevOps community helps solidify Microsoft's place as an industry leader and will encourage adoption of their other products. |
Beta Was this translation helpful? Give feedback.
-
|
For me it is interaction with authenticated REST APIs. |
Beta Was this translation helpful? Give feedback.
-
|
Powershell would be perfect for doing a quick test of an API, but the Module in PS5 has many quirks that make it work very different from what I would expect. The PS7 version is far closer to the expected behavior. |
Beta Was this translation helpful? Give feedback.
-
|
yes please! |
Beta Was this translation helpful? Give feedback.
-
|
I should say: Why not? But that is part of the question @SydneyhSmith is asking. 😄 In any case, I'm in favor of making it ship in Windows! Working professionally with it for over a year and except GPO, VMM and a couple other modules I never had any problem with it. Most of the time it's even faster then when I would do it in 5.1. |
Beta Was this translation helpful? Give feedback.
-
|
Yes and get rid of PowerShell ISE and ship Visual Studio Code instead. |
Beta Was this translation helpful? Give feedback.
-
Neither do I. Including a development tool with Windows was a mistake. Such a tool is difficult to maintain and scale. Nowadays, PowerShell development requires complex tooling well beyond ISE, including NuGet, |
Beta Was this translation helpful? Give feedback.
-
|
At least one of those things ships with Windows. :) WinGet makes the rest easy. |
Beta Was this translation helpful? Give feedback.
-
|
A big difference between the ISE and VS Code is that ISE executes the script line by line while VS Code executes it as a Script. That causes issues with the script if e.g. you do not reset your aggregating arrays in between (because you do not need to in the script). Also variables like $PSScriptRoot do not work in ISE |
Beta Was this translation helpful? Give feedback.
-
|
I'd love an overhaul of the PS ISE if not a swap to vscode... |
Beta Was this translation helpful? Give feedback.
-
Alas, an outdated version that doesn't self upgrade! :( We need another discussion post setup to get the built-in WinGet updated as well. |
Beta Was this translation helpful? Give feedback.
-
|
Yes please. Here at the company I work for is already provisioning new VMs with PowerShell 7 ship in Windows. |
Beta Was this translation helpful? Give feedback.
-
|
Yes please! My company would never approve of installing PowerShell 7 as an extra product on Windows Server, so I am stuck with version 5.1. And I think a lot of people are in the same situation. Windows (Server) is still the most obvious place where people use PowerShell, and if you only provide a legacy version out of the box, eventually people will stop caring. If you want to keep PowerShell relevant and alive, PowerShell 7 needs to be the default on Windows. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, it’s unbelievable, that ms does not ship a current .Net or PowerShell with windows. |
Beta Was this translation helpful? Give feedback.
-
|
.NET 9 isn't a replacement for .NET Framework 4, though - those two are separate products, existing side-by-side. |
Beta Was this translation helpful? Give feedback.
-
|
Since day one, different versions of .NET have been installed side by side. No version of .NET has ever replaced another version. Binaries that depend on .NET version X cannot be satisfied by installing .NET version Y. Other than that, .NET 9 is the successor of .NET Framework 4.x and .NET Core 3.1, and a very competent one at that. .NET 9 has much higher performance. |
Beta Was this translation helpful? Give feedback.
-
This is Microsoft dogma. You need to upgrade your 4 to 6,7,8,9 and beyond. The controversy here is that Microsoft did not prioritize compatibility with its own product offerings, presumably to deter people and push them to the cloud. The Windows products have suffered considerably from things like not improving on the MMC, win32 based offerings, and instead focused on higher level abstractions like react and web based things which suffer from horrible performance. Has there ever been a hot steaming pile of poo bigger than WAC? |
Beta Was this translation helpful? Give feedback.
-
The strong compatibility requirement for .NET Framework 4.x has prevented many of the evolutions. You couldn't get all the improvements these years with full in-place compatibility. |
Beta Was this translation helpful? Give feedback.
-
|
At orgs without much ( see any ) shell adoption, it would be nice to have it in box for the small pockets of users who love The main reason I'm able to leverage winrm is because it comes in box with it enabled on modern Windows. I'd be stuck with If shipping in-box would slow down dev, then I think I would rather have it outside and fight the battle of deploying |
Beta Was this translation helpful? Give feedback.
-
|
Please have it preinstalled and be future thinking. Microsoft Graph module, Az module, SecretManagement module, etc. all heavily favor PS7 and in the corporate world, there are often tons of hoops to jump through to get it installed. Then constantly discovering various servers don't have it installed means when I'm trying to do some daily work, but my scripts don't work, another hold-up to get approval to get it installed...over and over. The future is clear that developers are targeting PS7 for modules. The risk/confusion of having 5.1 and 7 side-by-side should be irrelevant because anyone working with PS should know the difference and it would be a "growing pain" at worst. A good case study is all of the Server 2012 R2 machines out there that don't come with PS 5.1. To this day, at various customers, I'm STILL installing it all over the place after wondering why my scripts don't work. Don't make me do that again for PS7. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to see PowerShell 7 included natively for the simple reason that we're starting to see modules that are compatible with 7 only. The PnP.PowerShell module being the main example for me. It would also provide a good nudge to some developers to bring their existing PS5 only modules "up to code" as it were. |
Beta Was this translation helpful? Give feedback.
-
|
It would make things a lot easier, they can work side by side |
Beta Was this translation helpful? Give feedback.
-
|
It's truly amazing how oblivious some people are. The fraction of the Windows customer base that use PowerShell at all is incredibly tiny. The percentage of those people who have use for PowerShell Core that wouldn't work on Windows PowerShell is a minute fraction. Yet there are people on this discussion board who think that installing BOTH types of PowerShell, including all of their underlying dependencies (.NET and .NET Core), on EVERY installation would somehow make sense. Sure, Microsoft could make a snapshot of the then-latest PowerShell Core an optional component... but how is that easier to install that it is to install the latest version today? Frankly, I think it's more of a pain. And it would make every Windows image larger, the downloads (or USB stick creation) longer, and hardly used by anyone, as measured by percentages. It just doesn't make sense. And installing PowerShell Core instead of Windows PowerShell (in Windows) is not an option. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you. It shouldn't just be an addition; it should be a replacement. IMO PowerShell 2.0 and PowerShell ISE are great candidates for removal. They also make the Windows image smaller when they don't exist. |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely yes! 💯 But instead of just adding it, please remove the super old PowerShell ISE and Windows PowerShell 2.0. Like what is a realistic scenario right now that absolutely needs PowerShell 2.0? Why is it enabled by default when it was marked as deprecated 8 years ago? It doesn't have AMSI support so it's a security risk too to be enabled by default in 2024. Although in the near term, it's not possible to remove PowerShell 5.1 because too many built-in Windows PowerShell modules are not updated to use PowerShell (core) so they are proxied, but maybe start a project that begins making the compatible with PowerShell (core) ? If you add the modern PowerShell as MSIX packaged app to Windows it can be updated securely through Microsoft Store. |
Beta Was this translation helpful? Give feedback.
-
|
Server 2025 has removed the 2.0 engine https://learn.microsoft.com/en-us/windows-server/get-started/removed-deprecated-features-windows-server-2025#features-weve-removed-in-this-release. I would be surprised if ISE is removed before 5.1 is removed or at least turned into something like the 2.0 engine component.
I have no idea if there is some driver behind it but you can always see the latest compatibility matrix with the windows modules and powershell 7 at https://learn.microsoft.com/en-us/powershell/windows/module-compatibility?view=windowsserver2022-ps. I do agree that more work needs to be done here before 5.1 is booted out. |
Beta Was this translation helpful? Give feedback.
-
|
This is the default on Windows 11 24H2 which is what i was referring to, not Windows Server.
|
Beta Was this translation helpful? Give feedback.
-
|
This appears to already be in the works: Best to write new code for PowerShell 5.x+ but if you have the ability in your org to use 7.x go with that. :-) |
Beta Was this translation helpful? Give feedback.
-
|
I think it should be shipped with the OS for two reasons others have mentioned in some form or another. Having to justify installing PS 7 to Information Security and provide a software bill of materials for PowerShell 7 is a pain. Additionally, if software vendors knew they could rely on PS 7 being in place, at least one possible argument for why they don't upgrade their modules to support PS 7 (ActiveDirectory!) or why they don't target PS7 with built in tooling (InTune) would be gone. |
Beta Was this translation helpful? Give feedback.
-
|
Please don't. There are inherent differences between the PowerShell 5.1 and 6+. One of them is that the FIPS compliance configuration on Windows is ignored by the new PowerShell, because .Net Core team decided it's the application developer's responsibility. Therefore, new PowerShell has no capability for this at all. For this very specific case, it would be just adding a bypass method for hardening. This is only an example and has a lower impact, but the gist is, there are backwards incompatible changes that users are not aware of, that would cause corporate drama. It's better opt-in. PowerShell ecosystem and internal capabilities have been evolved in time as a helper for organizations to manage devices at scale, while PowerShell 7 is more focused on developer experience and cross platform usage. This caused leaving some features behind, making new PowerShell "not a replacement" for old one. I'd rather have a new PowerShell 5.x with some good features backported form PowerShell 7 |
Beta Was this translation helpful? Give feedback.
-
|
That was just an example and I agree that it's not a feasible setting. I guess I should have clarified my point better. I wanted to address that PS7 is not just a newer version but a newer product. The habitual assumptions expecting PS7 would act as is with some fancy new features is completely wrong. As PowerShell was designed to be shell on top of the OS, there were some ties and contracts, which are cut off due to cross platform operability requirement. So, the user's or sysadmin's solutions built upon years will start not working one day, and they would not understand why. That's why I want it opt in, so that it'd be a deliberate choice, not something that may cause accidents. Just like in a cockpit, the critical tools have different colors, or mechanism, so that the operator does not make a mistake: Some knobs require turning, others require pulling. The intention is preventing human errors.
|
Beta Was this translation helpful? Give feedback.
-
|
PowerShell was an opt-in from CMD, but both are still installed by default. None of the arguments in this thread apply to whether or not PowerShell 7+ should be provided, just to whether PowerShell 5.x should be removed (which it obviously can't). |
Beta Was this translation helpful? Give feedback.
-
|
Well, PowerShell is not a continuation of CMD. Users are well aware of the difference of the tools. PowerShell 5 to PowerShell 7 is not the same leap comparing to CMD to PowerShell 5. The difference is subtle and misleading. That's not an issue with home users, power users and developers. But in corporate setups, the difference is huge. Second, No one mentioned removal of anything. So, the argumentation looks like a straw man. |
Beta Was this translation helpful? Give feedback.
-
5.x should be an optional feature. I don't want obsolete packages on the OS. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with you to a point. But Windows is so intertwined with PowerShell 5.1, I don't believe it would be replaced that easy. To clarify, it is not a PowerShell 7 Team issue, but Windows OS Dev Team issue. Only after that integration, it makes a lot of sense. I do want that leap. But with the current state, I find it risky. |
Beta Was this translation helpful? Give feedback.
-
|
Lots in this discussion to think about. I think that it depends on version of Windows & which SKU we are all using IMO, at least with where we are today. Server 2025 - we just missed getting it added now that it's released. unless we are gonna get this via a Server 2025 R2 or feature update in the future. Now if Microsoft where to decide that there was a need for a side by side SKU to the Pro version of Windows Client OS called Developer, that included Pwsh and VSCode by default & other things too, I could get behind that as I expect many others would too. But by default on Home/Education/Pro/Enterprise SKU's, not so much so as the install methods for those rightly should be controlled by the user/administrators, and we are already seeing more installs on windows If a Developer version of the Client OS did come out, it definitely should not be tied to a paid VS Subscription, nor should it be like the Enterprise edition that's available via Eval Center & require re-installs every x days However I don't think YAWS (Yet Another Windows Sku) is what anyone really wants to have to work with, but that said SQL Server brought out a free developer SKU, and that helped lots of individuals and organisations build things. So a Developer Windows sku, is a question for the Windows team to think about & if it did happen, then it should have a different support lifecyle. ImplementationTaking a leaf from the OpenSSH implementation, and having PSv7 as a feature on demand (& making 5.1 a feature on demand too) might be the way to go for users/orgs that want it available in the base image (whether installed or installable), but for reasons either can't or aren't ever going to use other installation methods like from GitHub or WinGet, perhaps due to being totally disconnected from the internet. It makes little difference personally to me if it's in or not, as I'll be installing it with all the other things I want and need in my machines, which I can already do both in connected and disconnected scenarios easily enough. Editor considerationsIf you did inbox it, then whilst VS Code is the preferred editor of choice, I'd like to see ISE updated to enable either v5.1 or v7 as the engine of choice, only because we aren't asking about whether or not we should be adding VSCode and the PowerShell Extension too, which is an even bigger question to be asking than this one, though all of the above I think would apply to that question too.
3-5 years ago, this I think could have been a potential option, my concern is with the size of the team for an undertaking like this and how much has been added since v6, let alone all the changes in dotnet that would be needed to be backported too, which makes it anything but a small task. How do you decide on which features we backport and which we don't? 5.1 IMO, needs to be left as is, unless Steve & the rest of the team can get either an internal or external team with the same knowledge and size of the current team that is working on v7 and everything else around it to work on that in parallel to v7 & I think that's not only wasted effort, but very very unlikely UNLESS, there is a really the need for it, & should be discussed elsewhere as isn't the ask about v7 being shipped in Windows. Though who knows what will happen 🤷♂️
@jborean93 Whilst that's documented - It's still in the Eval Edition of Server 2025, as from my testing today so we need to remove this still ourselves - unless it's not there in the Azure or other images. Removing 5.1This is a no-go whilst there is a need for the compatability layer for modules that have not been updated Other Open Source Developed InclusionsWe've got Terminal, OpenSSH & Winget & more being being part of either default or optional features, which means that the Windows Team are at least willing to think about including more Open-developed products in Windows, irrespective of the support lifecycle. There seems little overall reason why we, couldn't have it included, but unlike adding Winget, Terminal, OpenSSH & others. there will be those that see adding it as another attack surface as well as being yet more bloat. Module UpdatesIf you box v7 in Windows, can we also please, please, please, get all current modules that only get updated via Windows Updates (all Windows\Sys32\ modules) moved from there into either Sum upI'm on the fence on this, but it would need to be an LTS version, not stable or preview if it were to end up there by default. |
Beta Was this translation helpful? Give feedback.
-
|
Combine both items and abstract 5.1 as an enabled Windows feature. In the future, this feature can be disabled and relegated to the archives of version 2.0. |
Beta Was this translation helpful? Give feedback.
-
|
Could it be possible to have both PowerShell 5.1 and 7.x shipped with Windows. Would that be any different than what we have to do now? It would save people in the community a step and make 7.x easier to find for new people to PowerShell. |
Beta Was this translation helpful? Give feedback.
-
|
@AnyOldName3, Microsoft cannot remove Windows PowerShell (i.e., PS5) from Windows, because that would break thousands of backward compatibility scenarios, despite many people wanting NO version of PowerShell in the OS, because 99% of customers don't use it, need it, or want it. PS7 is similar to PS5, but not the same, and not 100% compatible. So the only option would be to put BOTH versions, which would cause more unnecessary bloat. 99% of scenarios that require PowerShell work fine with Windows PowerShell, and 99% of the ones that don't work just fine with the user downloading and installing PowerShell Core. So, we're talking adding unnecessary bloat for everyone to make 1 out of 1,000,000 scenarios ever so slightly better. This isn't a tough call. This is a slam dunk. |
Beta Was this translation helpful? Give feedback.
-
|
No one's suggesting removing PowerShell 5.1. So many things still work with PowerShell 5.1 because people who write PowerShell scripts know that a lot of people refuse to install anything beyond what's there by default, so they've got no choice about what features they can use, and are unable to use any of the Core features, no matter how much less of a pain that would be. If Windows started bundling PowerShell 7 or later, then huge swathes of modules would start dropping support for 5.1, as their maintainers don't want to support 5.1, and would be able to make maintenance easier if they didn't have to, but do want to support the minimum version they can guarantee will be available. |
Beta Was this translation helpful? Give feedback.
-
Actually, yes, many people are. No PowerShell users/fans are, but many customers are asking for removing the bloat in the OS that less than 1% of users actually care about. And since Windows PowerShell can't be removed, adding another version would exacerbate this. This really isn't a tough decision. It's overwhelming the right call to allow users who want PowerShell Core to download it, and users who don't not to be burdened with it. |
Beta Was this translation helpful? Give feedback.
-
|
It's naive to claim PowerShell is bloat that people don't use in a similar way to how people could be tricked into deleting their system32 directories a decade or two ago. It's part of the OS and gets used by the OS, even if you're not interacting with it directly. |
Beta Was this translation helpful? Give feedback.
-
|
It's not naive. It's customer reports and telemetry. You are entitled to your opinion, but the data speak for themselves. |
Beta Was this translation helpful? Give feedback.
-
|
This is MS fault. They own the ecosystem, yet they can't/won't make things compatable across versions. When a language abandons the features that made it useful and can't get departments in their own organization to use it, it is a problem. This is where we are. All I hear are excuses about dotnetcore, win32, or COM or somethingelse left out, and noone is filling those gaps, yet they ship in modern win11,2025. Then the azure and graph modules break all the existing usages and the language has run amok. The versioning and inclusion is the least of it. It is turning into a fail. The community can't right the ship. I have changed my views on this and think powershell 5, cscript, dotnet, should all be removed and be provided external only. The c++ runtimes got it half right. |
Beta Was this translation helpful? Give feedback.
-
Two comparisons spring to mind....
Now in all these cases the program name is different. Same applies to pwsh.exe and PowerShell.exe, in other words they are not the same thing and not pretending to be. Pwsh.exe shares some environment with PowerShell and can use PowerShell modules but again the reverse is not the case. Now if PowerShell/pwsh just provided the scripting language itself and all cmdlets were from the store then this would have been much less of an issue, it would be each cmdlet or module's responsibility to be backward compatible, or else choose a version that is. It is not bash's problem if |
Beta Was this translation helpful? Give feedback.
-
|
Hi @SydneyhSmith, wondering if the survey is still ongoing? Are there any conclusions/actions at this point? |
Beta Was this translation helpful? Give feedback.
-
|
I half expecting/half hopeful that we will get an update from @SteveL-MSFT behalf as part of the 2025 roadmap for PowerShell blog post that should be coming very soon. However, I can't claim any insider knowledge on this at all & is just a guess (though my guesses are usually pretty good on things like this) Also until this discussion has an answer marked so that can be deemed as closed I'd think that it's safe to say that the survey is definitely ongoing |
Beta Was this translation helpful? Give feedback.
-
|
I think it should ship with Windows. I use PowerShell on Linux, and this affects my use in an indirect but important way. If my friend has some batch operation that they want to automate, and I want to write a script to do it for them, but they are on Windows and I am on Linux, I have to worry about whether or not the features I am using are in PowerShell 5. I have no way to directly test my scripts in PowerShell 5 on Linux. So this fundamentally serves to split the ecosystem. The divide becomes a double one, between Windows and Linux and 5 and 7. Of course I could tell them to install PowerShell 7, but that gets rid of a lot of the convenience of simply being able to give someone a script that they can run using a Windows feature. If distinguishing PowerShell 5 scripts from PowerShell 7 ones becomes an issue, I would gladly start adding some kind of shebang-like annotation to the top of my scripts if it meant that PowerShell 7 could become universally available. |
Beta Was this translation helpful? Give feedback.
-
is that what |
Beta Was this translation helpful? Give feedback.
-
|
This is a highly debated topic, with many opinions. I will contribute with my own:
|
Beta Was this translation helpful? Give feedback.
-
|
@rhubarb-geek-nz you may have missed that I was arguing for it being possible, not about whether it was worthwhile. There are many reasons not to that do not amount to making it impossible. For example, the CEO can say "I don't feel like it" to even the most mundane change, but that will never make it impossible--just that it won't happen anymore. In fact, "complicated and difficult" are very good reasons not to remove it until a critical mass (as I mentioned).
Your counter-arguments are weak:
There are many ways to ensure that such levels of destruction can be mitigated and that is your very next point, and I point I have made repeatedly as well. Side-by-side versions, upgrade paths, et cetera, when put into place, do result in people eventually living with it. There are also many cases where companies have failed to put such mitigations in place (of which your examples count), which does not dispute that many have been successful. Does someone getting hit by a bus when jay-walking mean that cross-walks are a failure?
"The lengths that are gone" is exactly what I alluded to by "complexity and difficulty". You are actually reinforcing my point.
If you read my full argumentation closely, I have never suggested to simply remove PowerShell 5.1. I have always suggested shipping them side-by-side to allow a transition as a mitigation strategy. You may have also missed that I am not just talking about migrating PowerShell, but also the .NET version of the OS. Considering how much Microsoft is pushing the new capabilities of the later .NET versions (including a completely new GUI engine than Windows Forms) there is a lot being missed out on .NET Framework. As I have already mentioned, there are a lot of applications moving to later .NET and Microsoft is likely waiting for them to hit a critical mass before migrating the OS to catch up--specifically because they do go to lengths to avoid breaking customers. When this occurs, moving PowerShell to a later version as well will be quite natural. But hey, that's my speculation (and hope). |
Beta Was this translation helpful? Give feedback.
-
My impression was that you thought breaking end users' scripts was no big deal.
Given PowerShell is used for automating business processes then breaking automated deployments is exactly the CrowdStrike scenario, and breaking end of day processing is exactly the same as the Post Office problems. |
Beta Was this translation helpful? Give feedback.
-
|
My apologies if I was misleading. Simply put: innovation and development naturally lead to breaking changes at some point. You can do a lot to improve a product without breaking changes, but at some point you will have to break something to continue improving it. After you break it there is a lot that you can do to mitigate the consequences. However, what you can never mitigate is people's emotional attachment to the old way. |
Beta Was this translation helpful? Give feedback.
-
|
What makes it not exactly the same is that both versions of PowerShell are known to be working. CrowdStrike resulted in an upload of a broken version that left people with no ability to fix it on their end. The Post Office scandal was a broken piece of software that was deemed to be more "accurate" than the people. It may feel like using a different working version will break your existing automated deployments, but that is only temporary and fully within your power to make a plan and prevent downtime. Something not available to the other scenarios. Similar with the Python versions in Linux; despite it being a very different ecosystem, deployments (many supporting cloud infrastructure) were able to cut over their automation at the same time they cut over their Python version. This is because both were known working versions with known differences that can be fully vetted in a test environment before cutting over and achieving zero downtime. That is hardly the same "breaking" that CrowdStrike or Postal Office scandal causes--rather than a surprise break it comes with customer effort. |
Beta Was this translation helpful? Give feedback.
-
Absolutely not the case here. If anything here will get busier with people raising more issues and feature requests. |
Beta Was this translation helpful? Give feedback.
-
|
This is not the first time MS had to deal with this. Powershell 2.0, which came out in 2009 was just recently removed and shipped side by side with powershell 5.0
I my opinion the solution is dead simple. Ship both Pwsh and Powershell 5 with Windows preferably with Powershell 5.0 being marked as an optional component.
That way if a business has a need for Powershell 5 they have an option without holding back the whole ecosystem.
|
Beta Was this translation helpful? Give feedback.
-
|
Yes, yes, a thousand times yes. I'm currently going through the pains of setting up an IIS server just so that I can have a v2 NuGet index for my custom powershell module repository. I hate it! There are so many, better, solutions but they all only support v3! Here I am with thousands of computers still squatting on a waaaaay more outdated PS5.1 and have to jump through hoops to support some archaic feature. Install-Module and PSResource function perfectly fine side-to-side! Why can't you just ship both and end my misery!? |
Beta Was this translation helpful? Give feedback.
-
|
ps7 and 5 bot support v2 and v3 repos, v2 being powershellget/packagemanagment and v3 being Microsoft.PowerShell.PSResourceGet |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Collecting user input/scenarios as to the challenges of not having PowerShell 7 ship in Windows and reasons why or why not PowerShell 7.x should ship in Windows.
Beta Was this translation helpful? Give feedback.
All reactions