Raise minimum version of PowerShell Core from 6.0.2 to 6.1.0 or 6.1.3

[bergmeister]

Currently the minimum version of PSCore required by PSSA is 6.0.2 (because previous Nuget packages of SMA had a bug).
Due to PSCore 6.0 reaching its end of life this month (as far as I am aware), should we bump the minimum required version to 6.1.0. or even 6.1.3?
We have 2 places in code that we'd adapt:

• The smoke check here to give a user facing message
  

  PSScriptAnalyzer/Engine/PSScriptAnalyzer.psm1

  Lines 16 to 17 in 7d850bb

  	if ($PSVersionTable.PSVersion -lt [version]'6.0.2') {
  	throw "Minimum supported version of PSScriptAnalyzer for PowerShell Core is 6.0.2 but current version is '$($PSVersionTable.PSVersion)'. Please update PowerShell Core."

• The SMA reference here (PSSA is not on PowerShellStandard, which is non-trivial to start to use in this repo and would be a bigger task)
  

  PSScriptAnalyzer/Engine/Engine.csproj

  Line 65 in 7d850bb

  <PackageReference Include="System.Management.Automation" Version="6.0.2" />

Any opinions @JamesWTruher @rjmholt @SteveL-MSFT ?

[rjmholt]

Definitely worth moving off 6.0.2 to 6.1.3.

Moving to PSStandard is nice but is a fairly large effort.

You'd also lose a lot going to PSStandard for PS 3. For script rules that use AstVisitor2 I don't think it would be possible -- you can't inherit from a type by reflection. Instantly you'd lose most of the benefit from PSUseCompatibleSyntax for example. Those rules that use it would need to be rewritten to use the FindAll method instead.

The functional APIs on the other hand are easy to work with -- easily cached runtime tests determine what PowerShell version you're on, and then you can use reflection when you need to.

[bergmeister]

Yh, I agree that moving to PSStandard (which I would only do for the compilation against v5 and v6) is another big chunk of work.
Do you think it is too aggressive to require the latest patched version of PowerShell 6.1? There will be quite a few software systems (e.g. build servers) and users that haven't patched yet. 6.1.3 is quite recent, maybe something like 6.1.2 is more practical?

[rjmholt]

I think requiring 6.1 without being specific about the patch version (if possible) is the right way to go. It's how MSBuild and npm would go, and the idea of the patch is that there are no breaking changes in 6.1 from 6.1.0 to 6.1.3.

But with 6.0 being EOL, I think we are forced to give up 6.0 support (from the perspective of releasing "maintained" and "supported" software ourselves)