On Windows, when we do an update install with an MSI, the directory of $PSHome gets changed to reflect the version number. For example, C:\Program Files\PowerShell\6.0.0-beta.8 gets changed to C:\Program Files\PowerShell\6.0.0-beta.9.
Unfortunately, this breaks any user-created shortcuts that are hard-coded to the exact path of PowerShell. Similarly, apps like VS Code get hardcoded to that path and will break after an update install.
AFAICT, there's a couple of paths forward here:
- It might not matter at all once we move to
pwsh and add $PSHome to the PATH. Anyone who wants stability should build their shortcuts, VS Code preferences, and shell/batch scripts against pwsh and not the full path.
- We change behavior to only use the major and minor versions (e.g.
6.0 and 6.1and not the revision number). That way, when we update to 6.1 we can keep them side-by-side. However, that might not be desirable if we maintain strict semantic versioning (i.e. don't make breaking changes between minor versions).
- We change behavior to only use the major version (e.g.
6). This is similar to the Office or VS Code approach (e.g. Office12 vs. Office13). This may be overoptimizing if we never do a PowerShell 7, or it might be the right solution if we maintain strict semantic versioning.
My main goal here is not to over-optimize for an uncertain future. That's why I'm leaning towards 1, but I want to get people's thoughts.
On Windows, when we do an update install with an MSI, the directory of
$PSHomegets changed to reflect the version number. For example,C:\Program Files\PowerShell\6.0.0-beta.8gets changed toC:\Program Files\PowerShell\6.0.0-beta.9.Unfortunately, this breaks any user-created shortcuts that are hard-coded to the exact path of PowerShell. Similarly, apps like VS Code get hardcoded to that path and will break after an update install.
AFAICT, there's a couple of paths forward here:
pwshand add $PSHome to the PATH. Anyone who wants stability should build their shortcuts, VS Code preferences, and shell/batch scripts againstpwshand not the full path.6.0and6.1and not the revision number). That way, when we update to 6.1 we can keep them side-by-side. However, that might not be desirable if we maintain strict semantic versioning (i.e. don't make breaking changes between minor versions).6). This is similar to the Office or VS Code approach (e.g.Office12vs.Office13). This may be overoptimizing if we never do a PowerShell 7, or it might be the right solution if we maintain strict semantic versioning.My main goal here is not to over-optimize for an uncertain future. That's why I'm leaning towards 1, but I want to get people's thoughts.