Please feel free to provide feedback or file bugs here.

← PowerShell

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 http://powershell.org/wp/?p=33342.

112 votes
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Forgot password?
    Create a password
    I agree to the terms of service
    Signed in as (Sign out)
    Close
    Close

    We’ll send you updates on this idea

    Don JonesDon Jones shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    started  ·  Joey Aiello [MSFT]AdminJoey Aiello [MSFT] (Program Manager, Windows Server) responded  · 

    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: https://github.com/powershell/powershell/tags

    Still, we can definitely continue to improve the semantic version implementation. You can track (and contribute to!) the discussion on these improvements here: https://github.com/PowerShell/PowerShell/issues/2354

    Thanks,
    Joey

    Show previous admin responses (1)

    10 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Forgot password?
      Create a password
      I agree to the terms of service
      Signed in as (Sign out)
      Close
      Close
      Submitting...
      • Rob NelsonRob 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 WestlakeJessie 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 MarquetteKevin Marquette commented  ·   ·  Flag as inappropriate

        I think the Semantic versioning is the right call here. http://semver.org/

        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 McDerpDerp 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 SturmMartin Sturm commented  ·   ·  Flag as inappropriate

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

        .) $RealVersion (e.g. 5.1.7.2345)

      • Soumitra Kumar JanaSoumitra 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 MudgeJack 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 JonesDon 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.

      PowerShell: PowerShell Engine

      Feedback and Knowledge Base

      (thinking…)