This is opened in response to negativity around experimental features and only having opt-in functionality.
As the title says, this tracks the idea of having all experimental features turned on in the Preview version of PowerShell to provide experimental feature authors the ability to get feedback on newly added experimental features.
There may be exceptions to this rule on experimental features that are drastic but It’s the role of a maintainer of PowerShell/PowerShell committee to decide this.
For preview builds - experimental features are all on
For stable builds - experimental features are all off
cc @SteveL-MSFT @joeyaiello
That certainly seems like it would be a more productive use of experimental features and preview releases. I like it!
In order to help gather input, it may be useful to show some information about experimental features on startup in preview builds. Having them on by default with no UX describing them doesn't help with gathering feedback about them since they risk appearing just like new features that are not experimental to end users.
it may be useful to show some information about experimental features on startup in preview builds.
I agree that we could start with this before enabling experimental features by default.
it may be useful to show some information about experimental features on startup in preview builds
This will involve changes to ConsoleHost. As such we should be aware that other hosts will not get this feature - aka PowerShell Editor Services.
This will involve changes to ConsoleHost. As such we should be aware that other hosts will not get this feature - aka PowerShell Editor Services.
It wouldn't necessarily have to be implemented as messages sent directly to the host. I haven't dug into how PSES works, but what other options does it provide for conveying information about experimental features that the PS Team wants feedback on as part of the review process of a preview release?
For testing we enable experimental features one by one and run specific tests. Why is it not way for other (MSFT) projects? Also we have a cmdlet to enumerate experimental features so any project can monitor them.
It wouldn't necessarily have to be implemented as messages sent directly to the host.
Do you have an alternative?
I haven't dug into how PSES works, but what other options does it provide for conveying information about experimental features that the PS Team wants feedback on as part of the review process of a preview release?
Without doing any work in PSES? - Write-* cmdlets and Console API
With doing minimal work in PSES? - Sending a message to VSCode that sends a “toast” within vscode
I like the toast idea, but I think having a host-independent implementation would be best. 🤔
I know a fair few users who work with ConEmu, etc.
@PowerShell/powershell-committee reviewed this, we agree with turning on experimental features by default in preview releases, but PS-Committee needs to decide which ones become non-experimental for RC and any features staying experimental will be disabled by default in RC. Implementation should be to ship a config.json with the Preview.
:tada:This issue was addressed in #10228, which has now been successfully released as v7.0.0-preview.3.:tada:
Handy links:
Most helpful comment
In order to help gather input, it may be useful to show some information about experimental features on startup in preview builds. Having them on by default with no UX describing them doesn't help with gathering feedback about them since they risk appearing just like new features that are not experimental to end users.