Drop c/x nomenclature

[tysonjhayes]

A couple of days ago @smurawski made a blog post about dropping the c nomenclature from the resources. I think this is a great idea and think we should drop x as well. All my arguements boil down to, "why do we really need it?" It's on GitHub now, everyone can contriubte, and IMO we should be trying to push more stuff into these repros/projects and an forks that occur can be easily traceable through GitHub.

Thoughts?

[smurawski]

👍 My one caveat is that MS may want to reserve the right to pull the resources in-box and drop the x to differentiate them. However, now that there is a precedent for shipping open source in Windows (Pester and PowerShellPackageManagement), this might not be the case - so "off with the 'x'"!

[Iristyle]

FWIW, at Puppet we've had the same types of discussions around these prefixes and moving the resources in-box eventually. I'm personally in favor of no prefixes as well.

[ferventcoder]

Anything in xPSDesiredStateConfiguration might have issues dropping the x. :)

[nanalakshmanan]

Things are a lot different now than when we started the resource kit. So yes these should eventually be gone. As a start, once we are done integrating all community contributions, we should deprecate all the "c" versions. As a second step we should look into deprecating "x". We want to ensure that resources pertain to all best practices - like having tests, etc - before we drop the "x".

[smurawski]

@nanalakshmanan @dlwyatt @vors - I've started removing "c" resources (from PowerShellOrg) that did not have any changes since forking from the origin "x" resource. I'm also trying to get as may "c" resources shipped to the gallery, so we can focus on getting changes merged back to the "x" projects.

[vors]

👍

About merging changes from 'c' to 'x':
It takes a lot of time to review such changes, sometimes they rise questions, sometimes we don't want merge particular pieces, yada yada.
Also, there are some style-guide changes that needs to happen on almost every such PR to make our common tests happy. And sometimes PR's authors just ignore CI build red status.
On the our end, we usually don't review PRs that are not green and cla-signed. So we can end-up in a situation, when everybody want changes to be merged, but there is a miscommunication in expectations about who should do the next move. All this complications make it very easy to loose track on meaningful, complex PRs.

Here is how we can approach it: lets reference this issue in PR that merge 'c' changes to 'x' versions. Then [because GitHub does the awesome job about "cross issue / pr" mentioning] we would have a central place [this issue] to keep track of what need to be merged and prioritize these PR reviews.

[KarolKaczmarek]

Sounds like a simple yet efficient plan to coordinate this effort @vors

[tysonjhayes]

I like the plan so far @vors. 👍

[KarolKaczmarek]

The RFC on this has been posted here: PowerShell/PowerShell-RFC#10

[johlju]

There are now an updated Naming.md that deprecates both 'c' and 'x'.

The "x" prefix is no longer required. Resources that include the prefix are free to deprecate the convention going forward.

Similar to the "x" prefix, at the launch of DSC there was communication that people contributing their own DSC resources prefix it with "c". This was because the resource modules were distributed via TechNet. Since we have moved to GitHub, this requirement is no longer valid.

Resource modules can be named using 'Dsc' as a suffix, or not, see Module Naming for suggestions on how to name and tag modules.

If there are no outstanding questions in this issue, I suggest we close this issue.

[PlagueHO]

Wow - this one is old! It gets my vote too 😁

[johlju]

Closing this as solved as per the two previous comments.