Re-enable version number in the ".ps1" extension.

Background: The “1” in “.ps1” stands for PowerShell 1.0. But as 2.0 is compatible with 1.0, the script file kept using the .ps1 extension without starting .ps2.

Today PowerShell is being brought to Linux and macOS. There will be more and more breaking changes in PowerShell 6.0 and later. (One possible example is removing UNIX alias.) I think it’s time to create a mechanism to avoid breaking legacy code when making “breaking changes”. One way is to re-enable the version number in the .ps1 extension.

Assume we have PowerShell 6.0 installed. When invoking a script ends with .ps6, enable all new “breaking changes”. But if it’s .ps1, keep the behavior as the old version (best effort).

We can avoid breaking changes and keep backwards compatibility for the moment, but we can’t do it forever. We should have some mechanisms to keep backwards compatibility when introducing “breaking changes” to the new version, so that we will not fear making “breaking changes”.

Of course file name extension is not the only way to mark the version of a script. We can pick up another way if it’s better.

[McAndersDK]

I don´t see it as ‘.ps1’ ever have been about PowerShell Version 1.

it dictate the structure and content of the file.

Lets say Microsoft wanted support binary compiled script files. This would not work with a ‘.ps1’ file, but it could be supported with a ‘.ps2’ file.

So as I see it, the idea is that if Microsoft for some reason needed to change the structure of a script file, they could do it by bumping the number in the extension.

[cbellee]

Jeffrey Snover explained why the .ps1 file extension was retaIned In subsequent PowerShell releases a while back. The ‘1’ denotes the current side by side version rather than the current language version. Link and excerpt follow.

https://blogs.msdn.microsoft.com/powershell/2007/11/02/ctp-versioning/

PowerShell Scripts continue to use “.PS1”. We will continue to pursue this approach until there is a major change in the CLR or .NET frameworks which force us to go side-by-side. It is at that point that we’ll go from .PS1 to .PS2 . Until then we will stay with .PS1 and everything that runs today will continue to run in new releases. You might write a .PS1 script which takes advantage of a cmdlet/feature that is only available in V2. If you send this to someone that has PS V1, it will fail “in some way and at some time”. If it uses some new syntax, it will fail at parse time (with a PARSER error) but if it uses a new command line switch – it won’t fail until it tries to run that command. This is what #REQUIRES is all about. You start your script with #REQUIRES -Version 2 And we will check version #’s and produce a precise error message If you have a #REQUIRES –VERSION 1 in your script, it will continue to run just find on PowerShell (V2) CTP because it is compatible with V1.