Skip to content

Latest commit

 

History

History
68 lines (58 loc) · 3.54 KB

CONTRIBUTING.md

File metadata and controls

68 lines (58 loc) · 3.54 KB
Raw

Contributing to PowerSponse

Great, you decided to contribute! That's awesome!

Please file an issue if you need a new feature or found an inconvenient "situation" (bug) or get the code form Github, make a new branch, extend the functionality as its needed and make a pull request if you need a new feature or found an inconvenient "situation". See section What is PowerSponse? for an overview about the repo structure.

Please use the guidelines as references when implementing new functions and check current cmdlets how to use supporting functions.

Some general guidelines:

  • Functions must support the common parameters (e.g. -WhatIf)
  • Functions should support all methods: WMI, WinRM, External
  • Functions must return PowerSponse objects to be able to concatenate the output of different commands
  • Functions names must comply with the PowerShell approved verbs (see references below)
  • Functions should not throw an exception instead the field "reason" should contain the error message
  • Add Pester tests for new functionality in .\tests\Pester\
  • Register the feature to the $Repository variable (see PowerSponse.psm1)

Adding a new feature

  1. Implement feature in respect to the guidelines mentioned above.
  2. Add corresponding Pester tests where useful in /test/Pester.
  3. Add the name of a new cmdlet which is used by the users to the Export-ModuleMember list at the end of the module file (.psm1).
  4. Add the name of a new cmdlet to the FunctionsToExport list in the module description file (.psd1).
  5. Add relevant notes to the CHANGELOG.
  6. Add a new markdown help file in /docs with examples. See BUILD for information about generating the help file.
  7. Add new markdown help file to the overview in /docs/PowerSponse.md.
  8. Update the external help file. See BUILD for information about generating the help file.
  9. Update README if needed.
  10. Update tag file if needed. See BUILD for information about generating the tag file.

Making a new Release

  1. Update markdown help and external help file.
  2. Run the Pester tests. See BUILD. All tests must pass.
  3. Update CHANGELOG
    • Update information according to the current release.
    • Add new Unreleased section and update the link for comparison.
    • Add the new version number in the old unreleased section.
    • Add the version comparison link to the current release changelog section.
    • Add the current date at the end of the new header row
  4. Update ModuleVersion in the module description file (.psd1).
  5. Commit the changes
  6. Set a tag for the new version (e.g. "vx.x.x").
  7. Push the tag and the code changes to the repo.
  8. Add a new Github release and add release notes