René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Directory for $PSHome when updating on Windows with MSI","articleBody":"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`. \r\n\r\nUnfortunately, 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.\r\n\r\nAFAICT, there's a couple of paths forward here:\r\n1. 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.\r\n2. We change behavior to only use the major and minor versions (e.g. `6.0` and `6.1`and 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). \r\n3. 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.\r\n\r\nMy 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. ","author":{"url":"https://github.com/joeyaiello","@type":"Person","name":"joeyaiello"},"datePublished":"2017-10-25T08:47:22.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":10},"url":"https://github.com/5226/PowerShell/issues/5226"}