Skip to content

Your first release#

Process-PSModule uses pull requests for review and release metadata, and an important push to the default branch as the authority for stable publication. There is no manual publish step, no version file to edit, and no tag to push by hand.

The flow#

  1. Clone the repository, create a branch, and make your changes.
  2. Push the branch and open a pull request against main.
  3. The workflow builds the module, runs tests on Windows, Linux, and macOS, lints the repository, and reports back on the pull request.
  4. Apply a version label to declare release intent (see below). An unlabeled pull request defaults to a patch when Publish.Module.AutoPatching is enabled, which is the default.
  5. Merge the pull request. Its resulting important push to main runs the stable release: after the pipeline passes, it publishes the module to the PowerShell Gallery, creates a GitHub Release and tag for the tested commit, and deploys the documentation site unless site publication is configured to skip. The closed-pull-request event only cleans up prereleases.

An important direct push to the default branch, or a manual dispatch on that branch, also creates a stable patch release with commit-based notes. It has no pull-request labels or body to use as metadata.

Version labels#

Label Effect
major / breaking Bump MAJOR.
minor / feature Bump MINOR.
patch / fix Bump PATCH. This is the default for an unlabeled PR when AutoPatching is enabled.
Prerelease Publish a prerelease version from the pull request, before it is merged.
NoRelease Run the pipeline but skip publication.

Conflicting labels (for example major together with NoRelease) are rejected and block the merge. The label names are configurable — see Settings.

For the full model, including prerelease promotion and what a release produces, see Versioning and releases.

Testing before you merge#

Add the Prerelease label to publish a prerelease version from the open pull request. The prerelease is installable from the PowerShell Gallery but is not promoted as the latest stable version, so it can be validated before the pull request is merged. When the pull request is closed without merging, the prerelease versions and tags created for it are cleaned up automatically.

When nothing is released#

If a pull request or default-branch push only touches files outside the configured important-file patterns — documentation, CI tweaks, comment typos — the build, test, and publish stages are skipped and no release is created. A pull-request comment explains why for pull-request runs. See important-file change detection to change which paths trigger a release.

What runs when#

Not every job runs for every trigger. See the scenario matrix for the full table.