Skip to content

Explain pull request release intent #62

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lipkau merged 1 commit into from
Aug 25, 2026
Merged

Explain pull request release intent #62

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/Contributing/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,6 +69,7 @@ If a similar issue already exists, add your details there.
No matter if you are fixing a typo or shipping a new feature, changes are submitted through a Pull Request.

Start with **[Submitting A PR](submitting-a-pr.html)** for the full flow.
The guide also explains the release and changelog labels required before a pull request can merge.

### 🧰 Development Container

Expand Down
23 changes: 22 additions & 1 deletion docs/Contributing/submitting-a-pr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,8 @@ If this is your first PR, you are in the right place.
3. Create a feature branch from `master`.
4. Implement the change (code + tests + docs where needed).
5. Run the repository validation steps.
6. Open a Pull Request to `AtlassianPS/<repo>:master`.
6. Declare the release and changelog intent.
7. Open a Pull Request to `AtlassianPS/<repo>:master`.

No stress if you do not get everything perfect on the first try. Reviews are collaborative.

Expand Down Expand Up @@ -67,6 +68,19 @@ Keep your branch focused on one change set. Small PRs are easier to review and m
- Update docs for user-facing changes.
- Keep commits scoped and readable.

### Declaring release intent

Every pull request must have exactly one release label:

- `release:none` for internal work that should not independently publish a package;
- `release:patch` for a backward-compatible fix;
- `release:minor` for backward-compatible functionality; or
- `release:major` for a breaking change.

A patch, minor, or major change also needs one `changelog:*` label.
Use a `.changelog/<pr-number>.<impact>.<type>.md` fragment instead when the public release note needs wording that differs from the pull request title.
The `Release Intent` check explains missing or conflicting labels directly on the pull request.

Additional references:

- [How to write a function](writing-functions.html)
Expand All @@ -78,6 +92,13 @@ Run the validation commands defined by the target repository before opening a PR

> **Important:** Always run the repository's validation commands before opening or updating your PR.

PowerShell module repositories normally use:

```powershell
./Tools/setup.ps1
Invoke-Build -Task Build, Test
```

For `AtlassianPS.github.io`, run:

```bash
Expand Down