Skip to content

Decide on which experimental features will remain in experimental in 7.0 #11302

@joeyaiello

Description

@joeyaiello

Going into RC, we have to make a decision on whether experimental features are "graduated" to stable vs. staying as experimental.

Per some conversations with the @PowerShell/powershell-committee, this is our current position on each:

Stable

PSCoalescingOperators
PSErrorView
PSForEachObjectParallel
PSPipelineChainOperators
PSTernaryOperator
PSUpdatesNotification
PSWindowsPowerShellCompatibility
Microsoft.PowerShell.Utility.PSGetError

Experimental

  • PSCommandNotFoundSuggestion: the suggestion infrastructure has proven to have some serious issues that break this feature (e.g. it's not shown at all in VS Code)
  • PSImplicitRemotingBatching: this has not had enough significant usage (both internally and externally) for us to feel confident about it
  • PSNullConditionalOperators: this is only the null conditional member access aspect of the null conditional operators
  • PSUnixFileState: this could still have unknown performance implications, and we still might want to change the property names on the returned information
  • Microsoft.PowerShell.Utility.PSManageBreakpointsInRunspace: this one will likely be getting some last minute work from @TylerLeonhardt to support a feature needed in vscode-powershell. Given the risk of these last minute changes, we don't want to promote this to stable in 7.0.
  • PSDesiredStateConfiguration.InvokeDscResource: this has some limitations compared to the Invoke-DscResource shipped in Windows PS that we'd like to address before graduating it.

Metadata

Metadata

Assignees

Labels

Area-Maintainers-Buildspecific to affecting the buildIssue-Enhancementthe issue is more of a feature request than a bug

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions