Skip to content

Conversation

@SteveL-MSFT
Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Dec 9, 2019

PR Summary

As discussed in @PowerShell/powershell-committee, these features will be out of Experimental status:

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

Code marking them as Experimental has been removed.

PR Context

Fix #11302
Fix #11081

PR Checklist

Copy link

@anmenaga anmenaga left a 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:

  1. 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.
  2. As continuation from #1 if something goes wrong because of this feature - currently the only mechanism to turn it off is ExperimentalFeature switch.

@ghost ghost added the Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept label Dec 9, 2019
@ghost ghost removed the Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept label Dec 9, 2019
@SteveL-MSFT
Copy link
Member Author

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"))
Copy link
Collaborator

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.

Copy link
Collaborator

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.

Copy link
Member Author

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.0

Copy link
Collaborator

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

Copy link
Member

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.

Copy link
Member Author

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.

@SteveL-MSFT
Copy link
Member Author

@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.

@ghost ghost added the Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept label Dec 9, 2019
Copy link
Contributor

@PaulHigin PaulHigin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ghost ghost removed the Waiting on Author The PR was reviewed and requires changes or comments from the author before being accept label Dec 9, 2019
@adityapatwardhan
Copy link
Member

@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"))
Copy link
Member

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.

@daxian-dbw
Copy link
Member

I only reviewed the code changes related to ternary operator and update notification. Feature owners please review changes related to your features and sign off.

@daxian-dbw
Copy link
Member

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 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?

@SteveL-MSFT
Copy link
Member Author

@daxian-dbw I opened a new issue #11309 which we can accept for GA

@adityapatwardhan
Copy link
Member

@SteveL-MSFT Please fix build failures.

@adityapatwardhan
Copy link
Member

@daxian-dbw Please re-review.

@@ -1,7 +1,5 @@
{
"ExperimentalFeatures": {
"ExpTest.FeatureOne": [ "test/powershell/engine/ExperimentalFeature/ExperimentalFeature.Basic.Tests.ps1" ],
Copy link
Member

@daxian-dbw daxian-dbw Dec 10, 2019

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.

@adityapatwardhan adityapatwardhan merged commit ed1f6e3 into PowerShell:master Dec 10, 2019
TravisEz13 pushed a commit that referenced this pull request Dec 11, 2019
# Conflicts:
#	src/System.Management.Automation/engine/ExperimentalFeature/ExperimentalFeature.cs
@TravisEz13 TravisEz13 modified the milestones: rc.1-approved, 7.0.0-rc.1 Dec 11, 2019
@iSazonov
Copy link
Collaborator

Make sense to add CL- label?

@daxian-dbw daxian-dbw added the CL-Engine Indicates that a PR should be marked as an engine change in the Change Log label Dec 13, 2019
@ghost
Copy link

ghost commented Dec 16, 2019

🎉v7.0.0-rc.1 has been released which incorporates this pull request.:tada:

Handy links:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-Engine Indicates that a PR should be marked as an engine change in the Change Log MustHave

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Decide on which experimental features will remain in experimental in 7.0 Certain errors are not shown when all experimental features are disabled

9 participants