PowerShell Core 6.1 Roadmap

Steve

January 24th, 2018

The release of PowerShell Core 6.0 is only the beginning and we are already thinking about the next leg of our journey.

Most of the effort of the team with PowerShell Core 6.0 was in these areas:

Learning how to work in an Open Source project (and we are still learning)

Complete the port of PowerShell to CoreCLR

Add test coverage for PowerShell Core

Build/integrate tooling for automating builds, packaging, test execution, and releases

The community did some amazing work to add new capabilities in both the engine as well as cmdlets!

If you participated in the January 2018 Community Call you already got an early preview of this content.

Timeline

First, we’re publishing PowerShell Core 6.0.1 as a servicing release by the end of January in order to update to .NET Core 2.0.5. There are no other changes in the 6.0.1 release.

After that, the plan going forward is to have new supported minor releases every 6 months. This means that we’re targeting a late June, early July 2018 release for PSCore 6.1.

We will continue to have preview releases approximately every 3 weeks.

RFCs for new features we plan to deliver will be published in February.

Milestone Quality

There’s some work that we deferred and will be a focus to be completed in February:

Complete PowerShell Standard SDK – including guidance on converting Windows PowerShell modules to portable modules that are also PowerShell Core compatible

Author documentation in the Docs Repo for issues/PRs labeled with Documentation Needed

Docs Repo for issues/PRs labeled with Backport changes in PowerShell Core 6.0 to Windows PowerShell 5.1 for issues/PRs labeled with Consider-WindowsPowerShell51 Note that depending on the risk of the change, even if an issue/PR has this labeled, it doesn’t guarantee it’ll be backported

Enable automated test runs for all supported distros/platforms

Build infrastructure and tooling for cross system remoting tests

Have consistency and meet compliance requirements for the following repos: PSEditorServices VSCode-PowerShell PSScriptAnalyzer Archive Module PSRP WSMan Client for non-Windows



New Features

Being an open source project means that different people can invest in different priorities and submit their changes via pull requests, these are the areas that the PowerShell team will be focusing on. Some of these will be complete while others may be just the start of something bigger.

Security Parity with Windows PowerShell

The original port of PowerShell stubbed out support for DeviceGuard/AppLocker because those APIs were not available on Nano Server. This work will ensure that DeviceGuard/AppLocker policies are enforced in PowerShell Core 6.0 on Windows systems.

Run Signed Script Blocks Remotely

PowerShell supports restricting access using constrained language mode and only allowing signed scripts with a trusted certificate to run with Full Language mode. This new capability will allow using Invoke-Command to remotely execute a signed script block on a target locked down system with Full Language mode.

Windows PowerShell Compatibility Pack

With the announcement of the Windows Compatibility Pack for .NET Core for .NET Core, PowerShell Core will regain some APIs that had been dropped in the transition to .NET Core. This means we can re-enable some cmdlets that weren’t part of the PowerShell Core 6.0 release: WMI, EventLog, and PerfCounters. In addition, some highly requested APIs will be available which means that some existing Windows PowerShell modules might just work in PowerShell Core 6.0. This module will replace the WindowsPSModulePath module to add the Windows PowerShell $env:PSModulePath to PowerShell Core 6.0. Finally, we can use this module to optionally add back some aliases that we removed from PowerShell Core 6.0 that exist in Windows PowerShell.

Concurrency in PowerShell Script

You can do threading today in PowerShell using runspaces, however, it may be complex for some users. Rather than spend time creating something from scratch, we’re evaluating two existing modules that might already meet our needs:

PSThreadJob created by one of engineers on my team, Paul

created by one of engineers on my team, Paul PoshRSJob created by a PowerShell MVP, Boe

PSReadLine 2.0 GA

PSReadLine is our default interactive experience on Windows PowerShell 5.1 and PowerShell Core 6.0. This is a side project by Jason Shirk who recently put out a Beta1 release of 2.0. Some of my engineers will be spending time contributing to this project to get it to production quality so we can include it in PowerShell Core 6.0.

Machine Learning and PowerShell

A new area that we want to explore is leveraging the cloud and machine learning to provide inline suggestions at the interactive command-line. The two primary scenarios I want to target is to support both local and cloud based suggestions. This is a completely new area for the team so expect the initial release to be limited, but something we can build upon going forward.

An RFC will be published for this feature.

Experimental Feature Flags

As we build new capabilities, some features may not be fully complete where we don’t have sufficient community feedback. Being experimental, we may make large design changes that would not be backwards compatible. Users can choose to not use these features by not opting into turning on these feature flags. Feature flags can also allow us to have two different implementations of the same feature (that could not work side-by-side) and collect feedback that way.

An RFC will be published for this feature.

HelpSystem as a Module

This is the start of a bigger work item to componentize PowerShell so that we can have a smaller distribution of PowerShell Core for managed targets that don’t need all of the interactive experience components.

PowerShell help content today is written in XML. However, our docs are maintained as Markdown and we have platyPS that converts the Markdown to XML. We want to remove the need to convert to XML and have the HelpSystem use Markdown natively. After this work is done, the help system would still be included with the general distribution of PowerShell Core as an independent module.

An RFC for this has already been published.

Markdown Rendering Support

In addition to help being in Markdown natively, we would like to be able to render in the console any Markdown. For example, error messages or script output can leverage Markdown to provide emphasis. Initially there will be limited rendering support, but this is something we can improve over time. For example, eventually supporting plug-able syntax highlighting for code fencing.

An RFC will be published for this feature.

Enable sudo to Work Over PowerShell Remoting (for non-Windows)

On Unix-based systems, administrators use sudo to elevate themselves to run administrator tasks requiring higher privilege. Due to how sudo works, PowerShell remoting is not able to pass the request for the administrator password prompt from sudo . Note that sudo works perfectly fine locally in PowerShell Core 6.0.

Enable-SSHRemoting

PowerShell includes a Enable-PSRemoting command on Windows to make it easy to enable PowerShell remoting over WSMan using WinRM. This feature adds a new Enable-SSHRemoting command that would initially identify missing dependencies (like OpenSSH) and also configure sshd_config to enable PowerShell remoting over SSH.

An RFC for this has already been published.

PowerShell Module for IoT (Internet of Things)

PowerShell Core 6.0 has experimental support for ARM systems running Windows 10 IoT or Raspbian (Stretch).

To help bootstrap the community to develop more interesting uses for IoT using PowerShell, we want to provide the start of a module to enable using PowerShell script to interact with sensors attached to your IoT device. We would then work with the community to increase capability of this module over time.

An RFC will be published for this feature.

Closing

As you can see, we have a large set of work ahead of us for the 6.1 release.

The feature set was decided based on:

Existing customer feedback or known customer pain points

Driving towards longer goals through strategic investments

Specific partner/customer asks

Interests within the PSCore engineering team

The next 6 months will be lots of work, but it’ll also be fun. I also expect the community to continue to contribute new features beyond this list for 6.1. My team will continue to fix bugs, respond to issues, review PRs, and merge PRs while working on 6.1.

Please feel free to provide feedback on the PowerShell Core 6.1 Roadmap via GitHub!

Steve Lee Principal Engineering Manager PowerShell