Please feel free to provide feedback or file bugs here.

Version Numbering for All Releases

Please increment the version number for ALL releases, indicate which ones are supported in production, and provide a Get-PSVersionInfo cmdlet as described in

118 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

Don Jones shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

Hi everyone,

With PowerShell 6.0, we’ve already begun updating our versioning system to be more descriptive. Right now, PSVersion returns 6.0.0-alpha as a System.Management.Automation.SemanticVersion object (with Major, Minor, Patch, and Label properties), and we’ve also added a GitCommitId property to PSVersionTable that matches perfectly with tags on GitHub:

Still, we can definitely continue to improve the semantic version implementation. You can track (and contribute to!) the discussion on these improvements here:



Sign in
Password icon
Signed in as (Sign out)
  • Rob Nelson commented  ·   ·  Flag as inappropriate

    My request for semver (wow, over a year ago already) was specifically to use the PATCH level. It seems like every patch to say a WMF providing powershell 5 would also be version 5.0.0 rather than 5.0.1, 5.0.2, etc. It's great if there are build dates and git commits somewhere, but simple X.Y.Z numbers should always increment. I think this will become more important as faster releases (hopefully!) occur with the project hosted on github.

    Dependency tracking could use the standard '~>' style operators that you see elsewhere, where '~> 6.0' means the latest 6.anything, and '~> 6.1.0` means the latest 6.1.anything (>= 6.1.0, <6.2.0 is pretty close minus alpha release schemes).

  • Jessie Westlake commented  ·   ·  Flag as inappropriate

    I'm a Windows IT Pro that has just been getting into programming (thanks to PowerShell!) and even more recently into source/version control. I'm already realizing how much this is needed. Working in a TIGHTLY controlled, politic-laden, corporate production environment; I totally understand Microsoft's aversion to clouding the differentiation between preview and production products. I think we could get the best of both worlds by using beta identifiers. WMF 5.0 Beta 1, WMF 5.1.3 Beta 5, Beta 6, etc...

  • Kevin Marquette commented  ·   ·  Flag as inappropriate

    I think the Semantic versioning is the right call here.

    But I think the #requires -Version declaration should be looked at and possibly given a way to specify maximum supported version number. Same for the #requires -Module

  • Derp McDerp commented  ·   ·  Flag as inappropriate

    I wish PowerShell would use [version]::Revision to encode the release date e.g. 20160128 for Jan 28, 2016.

  • Martin Sturm commented  ·   ·  Flag as inappropriate

    .) $Version (Legacy) to satisfay the strict dependencies (e.g. 5.0)

    .) $RealVersion (e.g.

  • Soumitra Kumar Jana commented  ·   ·  Flag as inappropriate

    I totally agree with the idea of having a Get-PSVersionInfo cmdlet...This really makes the life easier to be up-to-date with latest version.

  • Jack Mudge commented  ·   ·  Flag as inappropriate

    "Unfortunately, there are some products which take strict dependencies on specific versions of PowerShell that may break as we iterate the version more rapidly."

    It's no different than it was before - products which strictly depend on a specific version would reference the specific version or version(s) that apply. I get the feeling that the reviewer missed the point of the suggestion...

  • Don Jones commented  ·   ·  Flag as inappropriate

    It does seem as if there's a middle ground. Perhaps keeping the traditional version number - the one in the file header or whatever software is checking for its dependencies - alone, but adding some internal-only piece of metadata. So you'd have the "5.0 branch" (e.g., the "visible" version number), and more specifically the "5.1 release." One serves as a broad compatibility indicator, while the other provides more specific intelligence, and can be hooked up to a "supported versions" list or lookup.

Feedback and Knowledge Base