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.
Don Jones
shared this idea
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
10 comments
-
Rob Nelson
commented
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
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
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 McDerp
commented
I wish PowerShell would use [version]::Revision to encode the release date e.g. 20160128 for Jan 28, 2016.
-
Martin Sturm
commented
.) $Version (Legacy) to satisfay the strict dependencies (e.g. 5.0)
.) $RealVersion (e.g. 5.1.7.2345)
-
Soumitra Kumar Jana commented
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
"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
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.
-
Rob Nelson
commented
+1 toSemVer versioning. That would be a huge improvement, while we're at it.
-
Roy Tinker
commented
Semantic versioning?