End support for PowerShell v3/v4 in VSCode-PowerShell v2.0.0

[rjmholt]

Currently, supporting PowerShell v3 and v4 creates several challenges for us:

• To get PSReadLine into the extension, we need changes coming in PSReadLine 2.0, which does not support v3/v4.

• We are forced to use the v3 AST to support v3, which means:

  • No support for classes or enums
  • Unable to use modern AST APIs

• Incompatibility in the APIs between v3, v4 and v5 mean that there are bugs that are hard to fix (and even hard to reproduce, since most of us don't have access to a machine running PowerShell v3 or v4).

• Of the two CI systems we currently use and the others we are looking to invest in, none supports PowerShell v3/v4 natively.

• v3/v4 usage is relatively low, and decreasing. With Windows Server 2019 around the corner and Server 2012 mainstream EOL also coming up this year, even more users will be moving to a newer PowerShell version.

• The code base is fragmented and hard to maintain because:

  • We have to compile against .NET Framework 4.5.1 and .NET Standard 1.6, when we would ideally compile against only .NET Standard. (This also spurs us toward better cross platform support)
  • We also have compile time PowerShell version targets.
  • Both of which lead to crazy .csproj files like this one.
  • The .NET Framework/Standard stuff means the backend codebase is riddled with #ifdefs.
  • There are also #ifdefs for v3/v4 support.
  • There's also version conditional logic in the build and run tooling, but that's easier to work with.

This issue contains most of the discussion that's already been had about dropping v3/v4.

My suggestion is:

• Include a deprecation warning for ~6 months, starting when v2.0.0 of the extension is released as stable.
• Actually drop support for v3 and v4 6 months after that date.
• Increment the major version number when we do it.
• Ensure that PSScriptAnalyzer can analyze PowerShell feature support by version so that people can still write scripts for v3 and v4 using the VSCode extension (but with the extension host running v5+).

Some additional things:

• An alternative to some of this is to refactor much of our code to abstract away the differences. However, that could be a costly effort and lead to significant regressions.
• We've also been talking about incrementing the major version of the extension with the addition of PSReadLine support. It seems a little cruel to me to drop v3/v4 support just as we add PSReadLine, but it also makes sense that both changes are big enough to mean a major version increase.

UPDATE

The addition of PSReadLine depends on a new version of PSReadLine that requires PowerShell v5.1 or later. This is by far our biggest motivating factor for ending support for PowerShell v3/v4.

[bergmeister]

PSSA supports v3/4 using pragmas and conditional compilation. This way you can use the latest API in in the versions of PowerShell where they make sense, i.e. a rule analysing classes does not make sense on ps v4.
If this is too much pain, then you should consider having a v2 of the extension in parallel (with the pain of merging important commits back to v1) but dropping support is not ideal. I can understand that it would be nice for us developers but keep in mind that it is also the job of a developer to put up with that complexity to make life as easy as possible for the user.
This issue is about VSCode but please also keep in mind that other parties might be using PowerShellEditorServices as well (I plan make either a WPF or Monaco based editor integration experience)

[SeeminglyScience]

@bergmeister that's what we currently do, but @rjmholt did a great job at outlining the issues with that. One of the biggest factors for me is the fact that we will only be able to support the latest version of PSReadLine, which requires PowerShell 5.1. Adding to that is the sizable amount of refactoring required to get PSRL working (often requiring newer PowerShell API's). Meaning we'd be supporting two wildly different experiences and code bases.

Also I suspect that the vast majority of folks are either stuck on version 2, or they're running 5.1 with very little in between. I'd be inclined to agree with you if we had the ability to support version 2, but we haven't since the beginning of the project (afaik). Granted this is anecdotal and based mostly on my own experiences and discussions with others, but I would be incredibly surprised if versions 3/4 made up more than 5% of PSES usage between them.

[bergmeister]

We are forced to use the v3 AST to support v3

What else do you expect? A user gets as many features as appropriate to the used version. By dropping support for v3 completely means that you change the feature coverage to 0%

Incompatibility in the APIs between v3, v4 and v5 mean that there are bugs that are hard to fix (and even hard to reproduce, since most of us don't have access to a machine running PowerShell v3 or v4).

Ok but it does not mean you have to fix all bugs in v3/4, you can still suggest users to upgrade should there be a blocking issue. Getting PowerShell v3/4 for testing purposes is as easy as creating a WinServer 2012/2012R2 VM, which takes less than 1 min to setup in Azure.

v3/v4 usage is relatively low, and decreasing. With Windows Server 2019 around the corner and Server 2012 mainstream EOL around the corner, even more users will be moving to a newer PowerShell version.

Customers use OSs that are supported by MS and they still run v 2/3/4 out of the box and with updates. Most of my customers don't even know there is a newer version of PowerShell. Users then have to take what they get in a corporate environment as they do not have admin rights to install stuff on their machine.

The code base is fragmented and hard to maintain

As I said that is sometimes part of our job but of course there is a limit at some point...

Your last argument about PSReadline is more interesting because it would be a technical and unavoidable reason. I think we need to split the discussion/deprecation into 2 parts:
For the VSCode extension it might be OK to drop support because there is still the ISE but PSES is supposed to be a general purpose library for usage by any 3rd party (including non-Microsoft!). If I embedded an editor into my app (for easier inline editing) that used PSES then I need this to work on any ps version that is installed on the client machine without having to force them to upgrade since scripts can break with the upgrade!

[rjmholt]

I've opened this issue just so that we can have an open discussion about pros and cons where anyone can weigh in. This issue properly belongs in the Editor Services repo, but this repo has more visibility so seemed like the right place to start the discussion. I'll open an issue in PSES to link back to this one.

@bergmeister you make excellent points, and we should also consider the possibilities of forking PSES and refactoring it to handle old versions properly.

We do have a responsibility as developers, but our time is finite and we should plan accordingly -- time spent maintaining a more complex, ultra-backward compatible codebase will mean less features, bugfixes and performance improvements. As PowerShell develops and changes, we will have to support that too, and we're going to have to decide what gets less attention or is dropped (which could just translate to "we support everything, but not as well").

As an open source project, users are also contributors, and to my mind the responsibility is shared.

[SeeminglyScience]

Ok but it does not mean you have to fix all bugs in v3/4, you can still suggest users to upgrade should there be a blocking issue.

If that's acceptable, why not use an old version of the extension if you need support for v3/4?

Getting PowerShell v3/4 is as easy as creating a WinServer 2012/2012R2 VM, which takes less than 1 min to setup in Azure.

That's a good solution for @rjmholt and @tylerl0706, but not for anyone else contributing to the project.

Customers use OSs that are supported by MS and they still run v 2/3/4 out of the box and with updates.

I have no doubt that tons of people are still running v2. But we already don't and can't support that one. What percentage are running 3/4 though?

Your last argument about PSReadline is more interesting because it would be a technical and unavoidable reason. ... For the VSCode extension it might be OK to drop support

Keep in mind PSRL is not a VSCode feature. The changes required are entirely within PSES and PSRL, any PSES enabled editor with a terminal will get the feature.

[TylerLeonhardt]

Lots of great discussion here. I'm on the side of revving the major version and back-porting important bug fixes back to the v1.

Sorry for being terse - traveling :)

[vexx32]

While some % of people are still on v3/v4 of PowerShell, i think that in large proportion these are not on machines where anyone will be doing any regular developing.

The ISE exists for one-off or occasional development work on those machines... But I think any serious PowerShell developer or sysadmin will be writing their code on 5.1, and many are starting to at least tinker with PS Core.

In other words, retaining overly complicated and time consuming support for these older platforms is unlikely to really benefit anyone we can maintain support for developing for these systems through version awareness (no classes when developing for PS v4, etc.), without needing to actually support development using these systems with the latest versions of these tools.

If you want similar functionality, there's nothing wrong with allowing people to still download and use the older versions that still support PowerShell versions 3 and 4, but I think it could be pretty hindering to both developers and users of these tools alike to unilaterally support as many older versions as we can.

It's a common problem: sure, we can spend exorbitant amounts of time and effort supporting older versions for as long as humanly possible. But I don't think we should.

[billkindle]

Still need time IMHO. Or at least give an option to switch to an older mode temporarily. Personally I have hoarded of systems that are on 2008 for another year or two. Yeah they are going to be replaced and yeah maybe still have ISE. I’m torn. I guess as long older versions would remain available for the fringe cases....

[Matalus]

I can understand the push to remove obsolete versions, but I'll make this argument, PowerShell tends to get used as a DevOps language, and at least in my case and I would wager many others. you don't always get to choose which version of PS the customers you're working with are using. While most of what I do is in v5, I know I have customers that are still running v2 and they have zero plans to update ever.

[rkeithhill]

As has been mentioned, the extension already does not support v2.

[vexx32]

Just because the tool is developed for PS 5.1 doesn't mean it can't support testing for compatibility for earlier versions of PS.

You just won't have access to the latest version for creation of scripts on these machines themselves. You can still verify that the scripts will work on the older machines, though.

You may not be able to choose what version of PS your customers are using, but there's no reason you have to develop in the exact same environment as your customers.

[dimitertodorov]

VSCode is mainly used on our development machines where it would be silly to run anything below 5.1

I develop a lot of Binary modules, and having C# interop work better would be great.
In particular, this issue would be great to close off.
PowerShell/PowerShellEditorServices#14

For testing, we always use remote machines for QA, and that is not dependent on having VSCode installed.