Entra PowerShell: Beta Module Naming Conventions #932
Replies: 9 comments 17 replies
-
|
I prefer seeing .Beta at the end, but all of the other Graph beta modules seem to use Microsoft.Graph.Beta.Thing so consistency is key. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer Microsoft.Entra and Microsoft.Entra.Beta. Just because these modules are based on Microsoft Graph, their names should not suggest that they are part of the Microsoft Graph PowerShell SDK. |
Beta Was this translation helpful? Give feedback.
-
Very good point. |
Beta Was this translation helpful? Give feedback.
-
Agreed. The documentation should state that they are based on graph, not the name. Explicit naming schemes are great but should still be concise with what they are. Having just Entra and Entra.Beta would work as well. I never understood why it has to have Microsoft.x. |
Beta Was this translation helpful? Give feedback.
-
|
Agree! 👌 |
Beta Was this translation helpful? Give feedback.
-
Agreed 1000% |
Beta Was this translation helpful? Give feedback.
-
|
+1 to Microsoft.Entra and Microsoft.Entra.Beta |
Beta Was this translation helpful? Give feedback.
-
|
I think the native SDK has hurt many of us in one way or the other, so as long as this module is planning to avoid causing the same emotional damage, I'd prefer to not see |
Beta Was this translation helpful? Give feedback.
-
|
Microsoft.Entra is more outstanding in my opinion and speaks for itself. Some of my co-workers are annoyed and don't want to have another module installed from the x amount of the same module. And I have a hard time to explain that this is NOT the case :) |
Beta Was this translation helpful? Give feedback.
-
|
I am no one but, why have Microsoft in the name at all? ActiveDirectory didn't need it. Nor did Azure I think. |
Beta Was this translation helpful? Give feedback.
-
|
It is to avoid any clashes when importing/publishing the module. In the same way as all Azure modules are Az.* |
Beta Was this translation helpful? Give feedback.
-
|
Hasn't the PowerShell Team mention something during PSConfEU about their plans to lock down these "namespaces" - I think this was the term they used - so only authorized teams/people would be able to publish modules with these trademark protected names? 🤔 |
Beta Was this translation helpful? Give feedback.
-
|
I just spent a few minutes looking for that information as I was certain I had heard that but couldnt find it written down anywhere |
Beta Was this translation helpful? Give feedback.
-
|
I did the same, looking at the AMA recording 😁 |
Beta Was this translation helpful? Give feedback.
-
|
Ah sounds familiar to me right now, it could have been the AMA session, yes :) |
Beta Was this translation helpful? Give feedback.
-
|
I much prefer that the name does not include graph as this is confusing for the general users of the modules as can be seen by the views stated by the expert users in the comments here. |
Beta Was this translation helpful? Give feedback.
-
|
Rather than Beta - why not call the early release version preview the way Teams does for their module? https://www.powershellgallery.com/packages/MicrosoftTeams/6.4.0 |
Beta Was this translation helpful? Give feedback.
-
|
Because of the Microsoft Graph beta endpoint. Microsoft.Entra targets v1.0 endpoint. |
Beta Was this translation helpful? Give feedback.
-
|
Was about to say exactly this! Thanks @alexandair |
Beta Was this translation helpful? Give feedback.
-
|
Got it, so it's less about the version of the module, but about which endpoint it's targeting. I get it now. Wasn't clear about that at the start. |
Beta Was this translation helpful? Give feedback.
-
That's helpful. I actually didn't realize that. |
Beta Was this translation helpful? Give feedback.
-
I'd ask that you make it clear about this being about the endpoint it targets. or don't build two, but build a way to have one module target either endpoint. |
Beta Was this translation helpful? Give feedback.
-
A clear explanation of that difference would be helpful. Still, having the two separate branches makes sense to me because building support for both endpoints in one module might end up feeling bloated and cumbersome because of the differences. |
Beta Was this translation helpful? Give feedback.
-
|
Originally the SDK itself was written with targeting the two endpoints in the same time and having the ability to switch between them, but it was actually way harder to not get lost because if you were running with the GA mode your script could have errored out trying to use a feature depending on the beta endpoint. I belive it's better to keep them separate as it's clearer to everyone reading the code which parts depend on which endpoint, plus you don't need to download the beta if your company has a policy against using beta endpoints. As splitting into the two flavors the actual size of the modules were halfed too. Ps: originally it might have been my issue which led to the split 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Closing the loop on this discussion - We heard you! Thanks to your feedback, we’ve renamed the module.
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We are seeking your valuable feedback on the Entra PowerShell module naming conventions. We've received feedback suggesting that the name "Microsoft.Graph.Beta.Entra" aligns well with the existing Microsoft Graph naming conventions. We would like to know your thoughts on this option. Does "Microsoft.Graph.Beta.Entra" resonate with you, or do you have alternative suggestions? Your input is crucial in helping us maintain clarity and consistency in our module names.
32 votes ·
Beta Was this translation helpful? Give feedback.
All reactions