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
JoeyJessie 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...
6 votesJessie Westlake commented
This is not a PowerShell bug per se, but I do think that the team should integrate a workaround or cmdlet that allows recalculating the permissions on FileSystem objects programmatically.
The actual issue here is that ACLs never recalculate programmatically in Windows, ever. There is behavior implemented in Windows Explorer that forces the ACLs to update whenever there is a change that would require it, so it seems like a bug whenever this doesn't happen.
The reason Copy-Item does not have this problem is that the files that end up in the Destination are NEW files, and as such those new files are assigned the default inherited ACL. When files are MOVED with Move-Item, they are they same exact files. Those files have essentially just had one property updated, and that property is the "Path" property. The path/location of a file is really just a piece of metadata. The only time a new file is created and would have a new ACL generated is when you are copying items across separate logical/physical drives. As a matter of fact, though, Dragging and Dropping files through Explorer often does not recalculate the ACLs either. Cutting and Pasting will create new files and should recalculate the ACLs.
I've had a serious problem with this issue while creating a set of cmdlets to manage NTFS permissions on our network shares. Essentially you have to iterate through EVERY SINGLE FILE and programmatically make a non-destructive change (like changing the inheritance protection and setting it back) before saving the ACL back to the file in order for it to update and recalculate its ACL with any inheritable permissions from its parent. I don't know how Windows Explorer does this so quickly, but this has taken me hours and hours to complete in a large collection of files, where it may take Explorer just a few minutes.
Thank you for the suggestion. Given the number of requests, we cannot field all recommendations, so for now we’ll be monitoring this to see if there is broad support.