<\/i>Important<\/strong><\/p>The intention of this article is to clarify that you cannot determine supportability by the name of a module. Indicators such as “x” DO NOT imply whether the module is supported or not supported. If the module is supported (Microsoft, 3rd party, or by an open source project) it should be documented in the ReadMe file, or made clear in product documentation.<\/div><\/p>\n When DSC was\u00a0announced<\/a>\u00a0at TechEd 2013, one of the\u00a0goals<\/a>\u00a0was to “Create an ecosystem”.<\/p>\n The ecosystem for DSC has grown tremendously in the last 4 years.<\/p>\n At worldwide events for PowerShell (PowerShell + DevOps Global Summit<\/a>,\u00a0PowerShell Conference EU<\/a>,\u00a0PowerShell Conference Asia<\/a>) there have been presentations lead by people actively using DSC to discuss real world, success, challenges, and community projects to resolve common issues. In addition there are community projects to build solutions for DSC entirely driven by the community, such as\u00a0Datum<\/a>\u00a0to manage configuration data at scale,\u00a0BaselineManagement<\/a>\u00a0to convert Group Policy to DSC configurations, and\u00a0ReverseDSC<\/a>\u00a0to replicate known environments.<\/p>\n The\u00a0PowerShell Gallery<\/a>\u00a0includes 1100 DSC Resources across 254 unique modules. Of those 1100 DSC Resources, 411 are currently released by the DSC team from the DSC Resource Kit.<\/p>\n During events and the monthly DSC Resource Kit community calls over the past year, I have heard consistently that\u00a0the naming convention for DSC Resources is ready for an update.<\/strong>\u00a0Most notably, the\u00a0experimental “x” prefix<\/a>\u00a0and\u00a0HQRM<\/a> guidance could be confusing and does not match the approach used in other similar community ecosystems.<\/p>\n The original recommendation was to name resources using the following prefixes:<\/p>\n Resources that met a community agreed upon quality bar, or “High Quality Resource Modules”, have been using a naming suffix “Dsc”.<\/p>\n The community has discussed and agreed upon a new simplified standard, explained in a recent update to the\u00a0documentation<\/a>.<\/p>\n DSC Resources going forward are no longer required to use the “x” or “c” naming conventions.<\/strong><\/p>\n Instead, the guideline is that resources should use either the existing module name (if DSC Resources are combined with an existing module containing PowerShell functions) or the “Dsc” suffix. The best practices for finding a DSC Resource module is to search the PowerShell Gallery using the “DSC Resource” filter, or use the cmdlet:<\/p>\n The project name will not have any relationship with how or whether the project is supported.\u00a0The\u00a0documentation<\/a>\u00a0merged today also addresses this topic.<\/p>\n This is only possible because the DSC community, especially the DSC Resource project maintainers, are so passionate and actively working with DSC users to make the ecosystem better for everyone. The maintainers hold each other accountable to quality and technically enforce this through test automation.<\/p>\n The first community contributions to the DSC Resource Kit contained only the PowerShell code for the DSC module. The expectation for a contribution today includes following best practices<\/a>, style guidelines<\/a>, documentation, and test<\/a> automation to demonstrate quality. As an example, the SharePointDsc module includes 2102 tests that must pass to accept a new contribution, and anyone can review the\u00a0results of a new build<\/a>. Similarly,\u00a0SQLServerDsc<\/a>\u00a0includes 2507 tests (and has already adopted the new naming standard),\u00a0xWebAdministration<\/a>\u00a0has 1032, and\u00a0xActiveDirectory<\/a>\u00a0includes 653.<\/p>\n The old naming convention using “x” and “c” prefixes required users to modify their code when switching from experimental to stable versions of a module.\u00a0 Support for DSC Resources should come from the organization supporting the technology that is being managed. The best way to make that clear is to express it in the project Readme. Just as someone interested in consuming the resource should review the project code and make sure it is suitable for their environment, they should review the entire project documentation.<\/p>\n Finally, this change does not need to be implemented “overnight”. As maintainers release future versions of their projects and determine they are ready, they can choose to retire the “x” convention. The PowerShell Gallery will provide access to future releases by the new name and the history of previous releases by the old name. The project repository will be the source of truth.<\/p>\nThe Old Naming Convention<\/h2>\n
\n
The New Naming Convention<\/h2>\n
Find-DscResource<\/span><\/pre>\n<\/div>\nWhy is it the right time to make this change<\/h2>\n
How do I know if a DSC Resource is supported<\/h2>\n
When will this change happen<\/h2>\n