PowerShell / WindowsCompatibility

Module that allows Windows PowerShell Modules to be used from PSCore6
Other
137 stars 33 forks source link

What's in a name #26

Open AdilHindistan opened 6 years ago

AdilHindistan commented 6 years ago

Sorry guys, @SteveL-MSFT has been hard at work and closed #21 while I was typing this. Just take it as a feedback. Thank you!

I've been following this thread and it seems this has been decided already so, probably late to comment but I hope that it helps(funny Steve just closed the issue when I was typing this) .

This whole "compatibility pack" naming in general is pretty confusing to someone who may not be paying close attention or is not a too familiar with .NET / PowerShell.

I personally had to do some googling to see what each of the following similarly named 'things' meant and did: Microsoft.Windows.Compatibility pack WindowsPowerShellCompatibility Pack PSCoreWindowsCompat So I am not sure renaming this to WindowsCompatibility 'module' is helping anyone trying to figure out what actually this does/means.

@iSazonov asked the right question, what's this module doing and from SteveL's answer, my understanding of it is that it allows access to "PowerShell Windows Modules and scripts".

If that understanding is correct, then would not you want the name to be more descriptive? PSWinCompat?

Even just PSCompat would work b/c well, I think the message people get is PowerShell (PS)--> Windows PowerShell Core (PSCore) --> X-Platform

SteveL-MSFT commented 6 years ago

@AdilHindistan sorry, was trying to close on it so I can publish it this week as promised :)

However, it's only v0.0.1, so nothing is considered set in stone for this module at this time, but we should still not change something without strong justification.

The original name (good or bad) WindowsPowerShellCompatibilityPack was to convey two things:

  1. using this module improves compatibility with Windows PowerShell
  2. it's a pack (multiple) things

The second point about being a pack is no longer true due to some recent decisions even though the original concept was a bigger module. So it made sense to drop that aspect. Of course, the name itself is derived from the .Net Windows Compatibility Pack which they actually ended up calling Microsoft.Windows.Compatibility on nuget.org.

For the new name, the discussion in @PowerShell/powershell-committee was to keep it as short as possible while conveying it's purpose. So WindowsCompatibility is about enabling use of Windows PowerShell modules from PowerShell Core 6 and was decided that was a descriptive yet (fairly) terse name. It's a PowerShell module, so there isn't a need to have WindowsPowerShellCompatibility.

The point about being search engine optimized didn't come up and you do bring up a fairly good point that searching for "Windows Compatibility" would bring up mostly unrelated web sites.

My team is actively working with Windows teams to enable their Windows PowerShell modules to work on PowerShell Core 6 natively, so the utility of the WindowsCompatibility module will be less relevant in the future (although still necessary for older versions of Windows which won't get the ported modules, but eventually people will move to newer versions of Windows...).

PSCompat wouldn't have worked as PowerShell refers to both Windows PowerShell and PowerShell Core. Even though PS is a commonly used and accepted abbreviation for PowerShell, best practice would be to spell out PSCompatibility and it would be less clear what that means (I think).

AdilHindistan commented 6 years ago

@SteveL-MSFT thanks for taking time to explain. I liked your announcement on twitter, so I will call it rModule :)

SteveL-MSFT commented 6 years ago

@AdilHindistan I still refer to it as rModule sometimes internally here, but I did notice that sometimes people think I'm saying our module.