-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Make approved features non-experimental #11303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
anmenaga
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would a comment be sufficient?
// Added in PS7.0There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
PaulHigin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.