Make approved features non-experimental#11303
Make approved features non-experimental#11303adityapatwardhan merged 5 commits intoPowerShell:masterfrom
Conversation
anmenaga
left a comment
There was a problem hiding this comment.
PSWindowsPowerShellCompatibility has to remain experimental. Primary reasons:
- not enough flight time yet. First time it appeared only few weeks ago in Preview 6. On high level this feature changes module load behavior for some modules so it has capability to change/mess up existing user scripts/scenarios that were running fine before it. We've seen this happened with ScheduledJobs and CertificateProvider.
This needs more flight time. - As continuation from #1 if something goes wrong because of this feature - currently the only mechanism to turn it off is ExperimentalFeature switch.
8829031 to
24821f2
Compare
|
CodeFactor issues are unrelated to my specific changes |
| // G binary-expression '?' new-lines:opt ternary-expression new-lines:opt ':' new-lines:opt ternary-expression | ||
|
|
||
| // TODO: remove this if-block when making 'ternary operator' an official feature. | ||
| if (!ExperimentalFeature.IsEnabled("PSTernaryOperator")) |
There was a problem hiding this comment.
Counterpoint here: if we want a backward compatible parser/tokenizer, we should keep some kind of static flags in so that we could eventually create an implementation where you can build instances of parsers targeting different versions or feature sets.
There was a problem hiding this comment.
Just preserving some element of the code in here will preserve enough information for us to unpick all this later.
There was a problem hiding this comment.
Would a comment be sufficient?
// Added in PS7.0There was a problem hiding this comment.
Comments won't really describe the way the logic branches, but if we really want to avoid different logic (or changing the conditions to const bools) then we can muddle through with something designed to look and be machine parseable for a regex like // ps7-expfeat:PSTernaryOperator or something
There was a problem hiding this comment.
If we really want to pursue the build instances of parsers targeting different versions or feature sets goal, then we will have to guard the to-be-removed code in a compiler definition, like #if PSV6 ... #endif. I can see why we want this but it won't really help unless we test those guarded code on regular basis, and eventually this will make the code difficult to maintain.
There was a problem hiding this comment.
Perhaps we should revisit this later.
|
@anmenaga if this feature becomes blocking/impactful negatively for customers, we would be ok taking a change to add a setting to powershell.config.json to disable this specific feature. |
|
@SteveL-MSFT Please resolve merge conflicts |
| // G binary-expression '?' new-lines:opt ternary-expression new-lines:opt ':' new-lines:opt ternary-expression | ||
|
|
||
| // TODO: remove this if-block when making 'ternary operator' an official feature. | ||
| if (!ExperimentalFeature.IsEnabled("PSTernaryOperator")) |
There was a problem hiding this comment.
If we really want to pursue the build instances of parsers targeting different versions or feature sets goal, then we will have to guard the to-be-removed code in a compiler definition, like #if PSV6 ... #endif. I can see why we want this but it won't really help unless we test those guarded code on regular basis, and eventually this will make the code difficult to maintain.
src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs
Show resolved
Hide resolved
src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs
Show resolved
Hide resolved
|
I only reviewed the code changes related to |
@SteveL-MSFT when are we going to know it becomes blocking? Do you mean after 7.0.0 GA, we can make changes in the servicing branch of 7.0.0 to add back the experimental feature declaration and checks for the win-module-compat work? |
|
@daxian-dbw I opened a new issue #11309 which we can accept for GA |
|
@SteveL-MSFT Please fix build failures. |
|
@daxian-dbw Please re-review. |
| @@ -1,7 +1,5 @@ | |||
| { | |||
| "ExperimentalFeatures": { | |||
| "ExpTest.FeatureOne": [ "test/powershell/engine/ExperimentalFeature/ExperimentalFeature.Basic.Tests.ps1" ], | |||
There was a problem hiding this comment.
Ideally, you should add entries for those features that are still kept as experimental, because otherwise, their tests will not be evaluated during the GA release build.
But their tests will still be run in our daily build (since all experimental features are enabled in daily builds), so that can be deferred to another PR.
# Conflicts: # src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs
|
Make sense to add CL- label? |
|
🎉 Handy links: |
PR Summary
As discussed in @PowerShell/powershell-committee, these features will be out of Experimental status:
Code marking them as Experimental has been removed.
PR Context
Fix #11302
Fix #11081
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:or[ WIP ]to the beginning of the title (theWIPbot will keep its status check atPendingwhile the prefix is present) and remove the prefix when the PR is ready.