Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please rename pwsh to PowerShell Core 1.0, not 6.0 #5165

Closed
JasonFossen opened this issue Oct 19, 2017 · 8 comments
Closed

Please rename pwsh to PowerShell Core 1.0, not 6.0 #5165

JasonFossen opened this issue Oct 19, 2017 · 8 comments
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Resolution-Answered The question is answered.

Comments

@JasonFossen
Copy link

Please rename "PowerShell Core 6.0" to "PowerShell Core 1.0" to avoid confusion and disappointment.

Reasons:

The PowerShell Core 1.0 executable has been renamed to "pwsh."

Pwsh is very different and limited in comparison to Windows PowerShell on Windows.

Pwsh DSC is going to be very different than DSC on Windows PowerShell.

Pwsh really is a 1.0 product (i.e., new), it's not a 6.0 product (i.e., with a decade of refinement).

Going with version 1.0 follows the pattern in version number changes for .NET and ASP.NET when they went to .NET Core 1.0 and ASP.NET Core 1.0 (they did not go to version 5.0, see http://www.hanselman.com/blog/ASPNET5IsDeadIntroducingASPNETCore10AndNETCore10.aspx).

Using the 1.0 version number will help to emphasize and explain the difference between Windows PowerShell and PowerShell Core. This helps to get the message out about cross-platform .NET Core in general, which was part of the reason for the version number choices for .NET Core and ASP.NET Core.

99% of admins and developers will assume that pwsh builds on top of and enhances Windows PowerShell 5.1, which is wrong. Using the 6.0 version number is going to cause confusion and disappointment. Changing the version number to 1.0 will help reduce this. There will inevitably be bugs and limitations in something as complex, cross-platform and ambitious as pwsh 1.0, but by using the 1.0 version number, it will reduce the disappointment because "after all, it's a new 1.0 product..." After a year of bug squashing, pwsh 2.0 can be released to reassure enterprise customers.

This will also help to protect the reputation of Windows PowerShell when there are complaints and griping in blogs, forums, twitter, etc. about the bugs in pwsh 1.0. Consider, which would be less bad: complaints about "PowerShell 6.0" or complaints about "PowerShell Core 1.0"? Again, very few people are going to be careful and precise in their distinction between Windows PowerShell and PowerShell Core, they are just going to say "PowerShell." Remember, those of us following the development of pwsh are a very tiny percentage of the overall IT market; so what might seem like a "big" version number change to us (here in our tiny bubble of an echo chamber on GitHub) will actually be an almost unnoticed change to the outside world.

Finally, what if Microsoft changes it's mind in the future about Windows PowerShell and wants to release a new major update to it? By having separate version tracks, someday there could be a "Windows PowerShell 6.0" without causing more confusion. A few years from now, if pwsh only has a tiny market share, pwsh will be deprecated and axed, but Windows PowerShell will still be popular and growing strong.

So, please consider renaming pwsh to "PowerShell Core 1.0" before it goes live, it's definitely not too late, there's still plenty of time.

Thanks,
Jason

@markekraus markekraus added the Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif label Oct 19, 2017
@thezim
Copy link
Contributor

thezim commented Oct 19, 2017

Quoting @joeyaiello

https://blogs.msdn.microsoft.com/powershell/2017/07/14/powershell-6-0-roadmap-coreclr-backwards-compatibility-and-more/

Note: while PowerShell Core 6.0 is cross-platform, there is also a PowerShell Core 5.0/5.1 released exclusively as part of Nano Server.

Naming to PowerShell Core 1.0 would be confusing in that respect.

Personally I think 6.0 is the better choice as it shows a linear progression of PowerShell regardless of the underlying framework.

@JasonFossen
Copy link
Author

Hi @thezim:

Good point about Nano, thank you.

Note that PowerShell is not a part of the Nano base container image anymore, and Nano installations as a percentage of Server installations is extremely small, and as a percentage of total machines with PowerShell installed, it is a tiny, tiny fraction of that. Besides, the future of PowerShell on Nano is pwsh, assuimg DevOps-style developers need PowerShell on Nano containers at all (they'll need it on their workstations and CI/CD servers, but perhaps not on the final Nano images outputted).

For "linear progression", it's only a progression in version numbering, not in actual capabilities or for backwards compatibility. Pwsh is not a superset of Windows PowerShell 5.1, it's a smaller subset. This is where the confusion and disappointment will enter as people "upgrade" from 5.1 to 6.0. If the cmdlets, parameters and other features were the same in pwsh, then I agree that the underlying framework would be irrelevant, but they're not the same at all.

Thank you for voting!

@iSazonov
Copy link
Collaborator

With upgrade from 5.1 to 6.0 customers expect enhancements in the language. In fact, we've lost a lot of functionality on the contrary. We're just misleading people.
Of course, the internal version must be 6. But the product we'd better rename. I would even remove the version number from the product name to show people that this is the first milestone - PowerShell Core Threshold.

@dragonwolf83
Copy link

PowerShell Core is not really a smaller subset of Windows PowerShell. The built-in cmdlets, language, and public APIs have not been simplified or fundamentally changed in a way that reduces functionality. In fact, many cmdlets like Invoke-WebRequest and Invoke-RestMethod are getting awesome enhancements in 6.0.

Are there breaking changes? Yes.
Are there breaking changes to some public APIs or language behaviors? Yes
Is that enough to justify it being a 1.0 product? Not really.

From Semantic Versioning

MAJOR version when you make incompatible API changes,

A 6.0 version meets that version requirement.

The only functionality I've seen reduced is that PowerShell deprecated features like PSSnap-In and Workflow were removed. This is perfectly fine to do in a progressing API. It just means that some 3rd party cmdlets need to be updated to support 6.0, hence the MAJOR increment.

There are some issues still to be worked out on backwards compatibility which may be what gives you that subset feel. I don't think backwards compatibility though justifies starting over with 1.0.

@markekraus
Copy link
Contributor

I think a major version is fine. php4 to php5 had some of the same concerns regarding gains and losses and certainly things written for 5 didn't always run on 4 and vice versa. But it was still PHP. It, too, went through a massive underlying engine change. Not to compare PHP to my beloved PowerShell, but it is a language peer of sorts.

Outside the built-in modules is where the greatest difference between Windows PowerShell 5 and PowerShell Core 6. Most of the core language features and cmdlets are compatible or only require minor tweaking. Not enough to warrant a completely new version base, IMO.

@iSazonov
Copy link
Collaborator

I work in enterprise and last year from time to time I tried to use PowerShell Core for everyday routine tasks. I can definitely say it doesn't work. After forcing to Utf8, I won't even be able to work properly in the interactive session.

I see how much progress has been made over the past year and proud of my bit contributions, but for us it's still a toy - nobody's going to let us use even CoreFX in a production environment, not that PowerShell Core. We have no confidence. Many scenarios in Corefx are still not tested. In PowerShell Core, even the test coverage is less than 60 percent actually even less. We do not have tests for remote scenarios in general, and for remote scenarios across different platforms, all the more.

You'll be interested to know that of the 297 cmdlets we have 247 for Windows - 17% loss and 205 for Unix - 40% loss.

We need to distinguish between developers and users. For the first, we have to be internal 6.0. For the second, we should not focus on this "6.0", which gives rise to unjustified expectations. Nobody advertises Windows 6.0, 6.1, 6.2 - we know them under different names.

@WernerMairl
Copy link

i'm working on Linux with PS Core over the last months....
I can only consider to try it (Ubuntu Desktop+ VSCode + Debugging)!

It does not feel like 6.0! It is more like 1.0!
I know that more projects (VSCode, Powershell Plugin, Powershell Editor Services) are involved here but for the end user only the full stack (Runtime, Editor and Debugger) counts...
but i'm happy if we are able to push the quality of the entire Linux Development Stack to a real 6.0 feeling...

@SteveL-MSFT SteveL-MSFT added the Resolution-Answered The question is answered. label Nov 16, 2017
@SteveL-MSFT
Copy link
Member

The feedback is appreciated and we went through the same discussion internally before settling on calling it PowerShell Core 6.0. At this time, we are not considering changing the version number. There are pros/cons to both 6.0 and 1.0, however, as an engine and platform, PSCore6 is a superset of Windows PowerShell 5.1 and for some cmdlets, this is also the case with addition of new capabilities. Certainly PSCore6 at this time has less cmdlet coverage than Windows PowerShell 5.1, but that will change over time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Discussion the issue may not have a clear classification yet. The issue may generate an RFC or may be reclassif Resolution-Answered The question is answered.
Projects
None yet
Development

No branches or pull requests

7 participants