|
| 1 | +# PowerShell Core Community Call - November 16, 2017 |
| 2 | + |
| 3 | +## Agenda |
| 4 | + |
| 5 | +* RC/GA tentative dates |
| 6 | +* Buckets of investment for 6.1 timeframe |
| 7 | +* Support lifecycle (unless people say I already talked about it last time) |
| 8 | +* Release automation |
| 9 | +* New Committee members (I remembered!) |
| 10 | +* Community questions |
| 11 | + * VS Code polish (seems to hang a lot?) |
| 12 | + * David Wilson leaving |
| 13 | + * PS Standard 5.1 timeline |
| 14 | + * Module manifest improvements for x-plat in 6.1 |
| 15 | + |
| 16 | +## Notes |
| 17 | + |
| 18 | +* RC *may* possibly land tomorrow (Fri, Nov 17), but don't be surprised if it slips to Monday (Nov 20) |
| 19 | +* Outstanding PRs not marked for 6.0 will be included as part of 6.1 |
| 20 | +* 6.1 beta likely won't start until February |
| 21 | +* 6.0 GA is targetting January 10, 2018 |
| 22 | + * of course, we can slip, but we'll do our best not to :) |
| 23 | + |
| 24 | +* Engineering systems and automation are a top priority for the 6.1 timeframe |
| 25 | + * Signing is purely manual today |
| 26 | + * At least 2 months of dev time in 2018 on engineering efficiency |
| 27 | + * Still taking PRs, but feature development will diminish in that timeframe |
| 28 | + * Some of this is internal in Azure as well |
| 29 | + |
| 30 | +* Most of the open-source tooling for PowerShell are now underneath Steve |
| 31 | + * This includes VS Code, Editor Services, Script Analyzer, Phosphor, platyPS, Plaster, Polaris, etc. |
| 32 | + * We want to drive consistency between our repos, so expect some shuffling of labels/process (with your input!) |
| 33 | + |
| 34 | +* PowerShell 6.1 feature priorities |
| 35 | + * Security parity with Windows PowerShell 5.1 |
| 36 | + * Improvements to OpenSSH-based PowerShell remoting (PSRP) |
| 37 | + * Performance, ease to configure, etc. |
| 38 | + * Concurrency/parallelism |
| 39 | + * RFC published by Bruce: TODO |
| 40 | + * Going to revisit this to make sure that it's still the right thing to do |
| 41 | + * Might just bless/endorse an existing community solution here |
| 42 | + * Help system improvements |
| 43 | + * Better rendering of the help (syntax highlighting, hyperlinks?) |
| 44 | + * Native Markdown support (no more MAML!) |
| 45 | + * Curses-*like* console UI |
| 46 | + * e.g. Out-GridView in your terminal |
| 47 | + * Experimental feature flags |
| 48 | + * Allows us to check-in unstable code that can be turned off |
| 49 | + * `-ComputerName` like parameter or attribute that can be easily added to cmdlets |
| 50 | + * `sudo Foo-Command` support from within a PowerShell runspace |
| 51 | + * IoT/ARM64 support for sensor manipulation |
| 52 | + * No ARM32 support in .NET Core today |
| 53 | + * Suggestion from Keith Hill: improved module manifest support for cross-platform |
| 54 | + * E.g. `ExportedFunctionsOnWindows` |
| 55 | + * Challenge here is always downlevel: any keys we add won't work on older versions |
| 56 | + |
| 57 | +* David Wilson has moved on from Microsoft |
| 58 | + * Tyler Leonhardt is joining Steve's team to work on tooling |
| 59 | + * Pushing out a patched VS Code release (hopefully this week?) |
| 60 | + * Another senior engineer will be ramped up on tooling post-RC |
| 61 | + * Props to Keith Hill for crushing it as a maintainer in the tooling space! |
| 62 | + * Plans are still in flux for priorities within tooling, but we'll have updates solution |
| 63 | + |
| 64 | +* PowerShell Standard 5.1 |
| 65 | + * Jim Truher is producing a PowerShellStandard.Library 5.1 |
| 66 | + * Hopefully we'll put something out by GA timeframe (even if it's not necessarily GA itself) |
| 67 | + * Again these are for building universal modules" that run across Windows PowerShell and PowerShell Core |
| 68 | + * PS Standard 3.0 was a *hugely* manual effort, so 5.1 is a bit more difficult than you'd expect |
| 69 | + * Have to review explicitly and manual |
| 70 | + |
| 71 | +* Documentation refresh for 6.0 GA |
| 72 | + * `Documentation-Needed` and `Breaking-Change` labels still need to be documented in PowerShell-Docs |
| 73 | + |
| 74 | +* New PowerShell Committee members |
| 75 | + * Dongbo Wang and Jim Truher have joined the Committee |
| 76 | + * Jim Truher was one of the original PMs on PowerShell, offers a ton of experience there |
| 77 | + * Dongbo Wang is an experienced developer and PowerShell Core and will also have a ton of insight to offer into the Committee |
| 78 | + * Hopefully this means we can move more quickly than before |
| 79 | + * We'd like to chew through some of our RFC backlog as well (and generally be more responsive there) |
| 80 | + * Jason Shirk (lzybkr) has left the Committee due to job committments, but will still be around in the community to contribute where he can |
| 81 | + |
| 82 | +* Release cadence and support lifecycle |
| 83 | + * Plan is to have a minor version release of PowerShell Core 6.x every 6 months |
| 84 | + * e.g. 6.1, 6.2, 6.3, etc. |
| 85 | + * Will still try to keep a 3-week release cadence of betas as well |
| 86 | + * We'll be adopting a modern support lifecycle for .0, possibly 6.1 or 6.2 as well |
| 87 | + * At some point in the future, we'll adopt a fixed lifecycle on a specific minor branch of 6.x (e.g. 6.1 or 6.2) |
| 88 | + |
| 89 | +* DSC Core |
| 90 | + * https://blogs.msdn.microsoft.com/powershell/2017/09/12/dsc-future-direction-update/ |
| 91 | + * DSC Resource Kit Community Call as well: https://github.com/PowerShell/DscResources/tree/master/CommunityCalls |
| 92 | + |
| 93 | +* How to think about divergence of features based on cross-platform support |
| 94 | + * e.g. Should we support something on Linux where it's not supported on macOS? |
| 95 | + * Let's take it case-by-case, generally we should only think of the split between Windows and non-Windows |
| 96 | + * But if functionality is needed enough and macOS is limited, we could make exceptions there. |
0 commit comments