Module Name

[markekraus]

@BrucePay @SteveL-MSFT

Are we happy with the Module Name?

WinCompatibilityPack is a bit of a mouth full.. and.. it doesn't much feel like a "pack" any more now that it's just a script module without the .NET Windows Compatibility Pack.

I am notoriously terrible at naming things, so I don't really have any good alternative suggestions. but a name change before an initial release might be the last time to do it.

[SteveL-MSFT]

Great question. This module is now smaller than originally anticipated. cc @joeyaiello @HemantMahawar

I would be fine just calling it rModule which is the primary capability now.

[iSazonov]

The module name should reflect its essence - what is the essence now? (Should be ReadMe.md updated too?

[markekraus]

On the surface, the essence is backwards compatibility with Windows PowerShell and restoring feature parity. At its core, it makes the process of remote module importing easier. Focusing on the remote importing capabilities may detract from the intent of the module and may not drive users to adopt.

I think my current gripe is just the "Pack" piece. The deliverables of this module have changed multiple times since this GitHub project was opened. It was originally meant to include the WCP and PSCore native cmdlets (like WMI) for Window PowerShell Compatibility, Then it was change to WCP+rModule, now it is just rModule.

But the intent of this module has not change since the project started: Windows PowerShell Compatibility and making it possible to run Windows PowerShell scripts with Windows PowerShell Dependencies on PowerShell Core with minimal changes

WindowsCompatibility, WinCompat, WindowsCompat, WinCompatibility, WinPSCompat...

[iSazonov]

I see we have modules with name length 'PSDesiredStateConfiguration'.Length = 27 and 'DirectAccessClientComponents'.Length = 28

'WindowsPowerShellCompatibility'.Length = 30.

We also discuss moving aliases to compatibility modules #5870 (although I've found another solution). Perhaps the names should be similar.

[SteveL-MSFT]

Originally, it was a Pack including WCP, rModule, Add-WindowsPSModulePath, potentially ported modules like WMI, and potentially Aliases we've since removed.

WCP is now part of PSCore6. Add-WindowsPSModulePath will be less relevant after we enable PSCore6.1 to automatically search some Windows paths. WMI/EventLog/etc... porting will be less relevant with rModule and some porting work. Aliases is still an open issue.

[SteveL-MSFT]

@PowerShell/powershell-committee should discuss this

[iSazonov]

after we enable PSCore6.1 to automatically search some Windows paths

Is this already done?

[daxian-dbw]

@iSazonov Not yet, but it's in plan/scope.

[joeyaiello]

I'm good with WindowsCompatibility

[SteveL-MSFT]

@PowerShell/powershell-committee reviewed this and settled on WindowsCompatibility as the module name

[markekraus]

Good Choice. I have a PR in to rename the module.

[daxian-dbw]

Can we rename this repository? There are only 7 forks from 4 developers, so shouldn't be too much churn.

[markekraus]

+1 for renaming the repo

[SteveL-MSFT]

Still early enough that a rename seems fine. Done.