Optional Features

[KirkMunro]

This RFC was originally proposed as part of a collection of RFCs in PR #187. I am separating those RFCs into separate PRs to better adhere to the RFC process.

[kilasuit]

I really like this idea especially for items like the different Splatting options being considered at the moment and would allow implemenations like PowerShell/PowerShell#10073 and the one that @KirkMunro has suggested in #179 to be used on an opt-in basis for the author's preference.

I can see this be of a lot of use with changing some of PowerShell's quirks whilst allowing for back compatability as well

[TylerLeonhardt]

I speak for myself in this post and not my team.

This to me seems like something that would be nice to have for the scenarios you have mentioned, but ultimately adds a ton of maintenance burden.

The testing matrix would be totally blown out. I forsee issues along the lines of:

I can only repro this if I have these 2 optional features enabled and this one not enabled

It's just not something that I feel we can feasibly maintain and manage.

And since everything is loaded into one process, there's no escaping the possibility that one optional feature affects another one...

And the mention of allowing modules flip on or off these optional features means you want something of a sandbox for each module (which really isn't truly possible due to everything being in process)... Or you run into problems where one module wants something on and the other doesn't which means Import-Module has to be updated and that piece of the code is not a trivial part to touch.

I agree that the idea gives contributors the ability to break things without breaking things... But at a huge cost that I don't think we can afford.

[KirkMunro]

I think there is some confusion here that I'd like to clear up.

First, the intent of optional features isn't to allow users to pick one of multiple. So @kilasuit, in the case of PowerShell/PowerShell#10073 vs #179, I think that we need to just choose the right one for the platform and move forward with it. I personally feel #179 buys us much more in that case, but regardless, that's just a decision that needs to be made by the product team.

I agree that the idea gives contributors the ability to break things without breaking things... But at a huge cost that I don't think we can afford.

On the topic of actual optional features, I have a few thoughts:

Most importantly, we need something. PowerShell has been around for many years, and there are some problems that we can just fix. By suggesting that optional features is not manageable, and by having a hard and fast stance against breaking changes, that's not helping. I don't mean you specifically, @TylerLeonhardt...I'm talking about the overall direction of PowerShell. There are things that can be fixed that would make the language much better for everyone, but we need someone to decide on the path we're going to take to get there. So what is it going to be?

If we go with Optional Features, this comes with some risk, as you pointed out @TylerLeonhardt, but if the bar is kept high for things that are actually allowed to be added as optional features, then you should be able to sufficiently manage that risk. i.e. Any feature added as optional must add significant tangible value to the point that it would be beneficial for the majority of the community if PowerShell just worked that way by default, but since it was not implemented that way at first, and since it would be a breaking change, we can only put the feature in as opt-in functionality. Further, some changes would not be good candidates for optional features due to how things are implemented internally within the engine. The point here is that this could be and would have to be managed appropriately to keep the risk you talked about down so that we can move forward here.

If optional features isn't the answer, then which of the following alternatives do we move forward with?

• New file extensions (e.g. ps2, psm2, psd2, etc.). This approach provides a clean break, but identifying exactly what we would like in such a clean break could be a very long discussion, and getting to the point where we have that functionality available could take a very long time to get there.

• A combination of new file extensions and optional features. We could use a few optional features while we work towards new file extensions for versioning, so that we can solve the bigger issues now while working towards a larger step forward over time. This allows us to solve some issues that can be solved via optional features cleanly, while giving us a vehicle to put other features that cannot be solved in an optional way into a vNext of the runtime.

• A major version break, where we take on specific breaking changes. We're explicitly not doing that for v7. But semver allows for breaking changes with major version updates, so could/should we do that? How do we handle the command line? Maybe major version breaking with SxS installation support for PowerShell would allow for such changes. But, we would obviously need to be careful that we're not pushing the burden of a support matrix that is hard to manage on end users with this approach.

• Something completely different, that won't take years to get to. Seriously, there are problems worth solving today, with the notion of breaking changes getting in the way, what do we do here?

Better than just suggesting why this isn't a good approach, please think hard about this and the alternatives and let's see if we can come up with something where we're willing to put a stake in the ground, giving us a starting point from which we can move forward.

[TylerLeonhardt]

Like I said, supporting "Optional Features" is just not maintainable IMO. We're not enough people and our testing matrix isn't there. IMO the PowerShell team can only afford to maintain one PowerShell. Optional Features or something similar to that, means we'd be maintaining multiple PowerShells.

Having different file extensions is 'better' but it still introduces another version of PowerShell... Plus I can't think of another language that has successfully versioned their file extensions... Imagine all of the tooling that would need to be changed... Let's draw from other languages to tackle this classic issue.

The right way IMO to properly get the breaking changes you're looking for are for us to introduce those breaking changes into the product because the community & team believe it's the right breaking change to take.

However the bar is so high for breaking changes because one of our primary focus is to replace Windows PowerShell and the only way to do that is to do it with as few breaking changes as possible.

With that said, that's not necessarily going to be the priority in the future. So that mindset of "its the ok to take this breaking change" will possibly be more relaxed in the future.

So my alternative proposal is to wait for PowerShell to be ready to take breaking changes. PowerShell 6+ needs to see more users moving from 5.1 - to do that, we have to maintain backwards compatibility.

[joeyaiello]

@PowerShell/powershell-committee reviewed this one and are rejecting on the following basis:

• This will significantly increase the maintenance/testing burden of PowerShell. @TylerLeonhardt 's reasoning here is very accurate.
• This will increase fragmentation of PowerShell, making it very hard to know if a script is going to work on a given runtime of PowerShell. #requires partially addresses that need, but nested or circular dependencies can get very hairy very quickly for module authors and their users.
• If something can be turned on/off in an existing PS session, it should be implemented as a module.
• We're incubating some things around making PowerShell more composable at package time, but we're going in a very different direction (with the intention being to remove things from the PowerShell engine if they're not needed in constrained environments). We have a blog coming out soon on 7.1 roadmap with some of these thoughts.
• If something can be merged into PowerShell as non-experimental, we should agree that it's useful to the vast majority of users, or it shouldn't be added.