Move to date-based versioning for the extension

[tmknight]

• Slack Community Chat: https://powershell.slack.com (you can sign-up at http://slack.poshcode.org/ for an invite)
• Gitter Chat: https://gitter.im/PowerShell/vscode-powershell
  I suggest that the preview version be different than the release version. Having them both (currently) be 2019.5.0 makes it nearly impossible to programatically determine which version is installed and also seems unorthodox in versioning nomenclature. Thoughts?

[TylerLeonhardt]

There were many reasons for switching to the date based versioning. See the original issue here: #1880

Unfortunately, the previous version scheme was a huge pain point that burned us due to limitations imposed by vscode and so the current versioning scheme is in affect for this reason.

If you want to programmatically check the version of the extension while running in the extension, you can check the PowerShell Editor Services version using:

$psEditor.EditorServicesVersion

or outside of vscode you can check via:

code-insiders --list-extensions | ? { $_ -match "powershell-preview" }

It’s not ideal, but until vscode addresses the “prerelease” problem we’re stuck with this for our own sake of maintaining it.

[tmknight]

I absolutely agree with the moving to date versioning. My suggestion was to not make it the same as the release version (e.g 2019.5.1 vs 2019.5.0).

As for suggestions in lieu of more explicit $host versioning, option 1 will work - I didn't think of that.

Suggestion 2, I did think of that route, though your suggestion will not return the enabled version, only if installed. You would need to do something like this:
if(code --status | Where-Object { $_ -match "ms-vscode.powershell-preview" }) { $true }

Thanks, again!

[TylerLeonhardt]

My suggestion was to not make it the same as the release version (e.g 2019.5.1 vs 2019.5.0).

Yeah this sounds easy, but it’s an off-by-one error waiting to happen. We already have tooling around the current versioning scheme to make sure we don’t mess up again… Id be hesitant to change that - which takes a lot of verification to make sure we’ve crossed our ‘t’s and dot our ‘i’s.

At this time, I don’t think we have the bandwidth to put more work into the versioning and would rather wait on vscode to give a solution to the “prerelease” problem.

As for suggestions in lieu of more explicit $host versioning, option 1 will work - I didn't think of that.

Keep in mind, this is the version of PowerShell Editor Services which follows a normal SemVer versioning scheme since it’s a library leveraged in vscode-powershell. What you get back is a Version type. Currently preview is version 2.0, and non-preview is 1.*. Eventually that API will need to return a SemVer Version type but for now it’s just Version.

[TylerLeonhardt]

I’m going to close this since we aren’t planning on doing any work in this space for now.

[tmknight]

All, good, thanks for the quick responses. Keep up the good work!