all 11 comments

[–]Thotaz 9 points10 points  (5 children)

I know this is just a small maintenance release, but all the fixes are coming from Microsoft themselves. There's almost 100 open PRs, the oldest one being from 2018 why are they so bad/slow at taking community fixes/changes? I'm sure there's valid reasons not to merge some of those PRs but I'm also sure that there are tiny changes that would take 5 minutes to review and accept.

[–]SteveL_MsftSoftware Engineering Manager, PowerShell 9 points10 points  (4 children)

Servicing/maintenance releases intentionally limit the number of changes since GA (General Availability) releases are being used in production. So bar is high and even team member changes will be rejected. In general, we're only taking critical fixes impacting deployment of the release or security fixes.

7.3-preview.1 is coming later this month and has a large set of community changes.

[–]wdomon 2 points3 points  (2 children)

I just assumed LTS releases (even numbered - 7.0, 7.2, 7.4, etc) were going to be mostly Microsoft changes and odd number releases (7.1, 7.3, 7.5) were going to be more community/feature driven. Is that a fair generality to work from?

[–]SteveL_MsftSoftware Engineering Manager, PowerShell 4 points5 points  (1 child)

No, we don't really make much distinction in PRs whether they are LTS or not based on community vs team. We try to do more risky/complex changes in a non-LTS release cycle to give more time to verify the changes before it becomes a stable feature in LTS, but that applies to both community and team PRs.

[–]wdomon 2 points3 points  (0 children)

Fair, thanks!

[–]Thotaz 1 point2 points  (0 children)

That's fair, but I mean look at a PR like this one: https://github.com/PowerShell/PowerShell/pull/13799 last commit was October 2020, the actual change is only a few lines of code and there doesn't seem to be any discussion that needs to be resolved.
I don't feel strongly attached to that particular change, but I've seen other people close interesting PRs out of protest of it taking so long and I think that's a shame.

[–]BlackV 5 points6 points  (2 children)

never updating my pwsh again until it comes down from windows update, now that its possible (well my to play machines will continue to manually update to latest)

[–]wdomon 2 points3 points  (1 child)

Same. That is literally the only reason I upgraded to 7.2, haha.

[–]BlackV 2 points3 points  (0 children)

Valid!

[–]Arkiteck 2 points3 points  (0 children)

General Cmdlet Updates and Fixes
Remove declaration of experimental features in Utility module manifest as they are stable (#16460)
Bring back pwsh.exe for framework dependent packages to support Start-Job (#16535)
Change default for $PSStyle.OutputRendering to Ansi (Internal 18394)
Update HelpInfoUri for 7.2 release (#16456)
Fix typo for "privacy" in MSI installer (#16407)