Skip to content

chore: expand CONTRIBUTING with dev and release workflows #15

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
phunkeler merged 1 commit into from
May 3, 2026
Merged

chore: expand CONTRIBUTING with dev and release workflows #15

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
57 changes: 47 additions & 10 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,51 @@
# Contributing

## Day-to-day development

1. Work on a feature branch, not directly on `main`:
```bash
git checkout -b feat/my-feature
```

2. Commit using the [Conventional Commits](#commit-messages) format — this is what drives the changelog and version bump.

3. Open a PR targeting `main`. The SonarCloud build must pass before merging.

4. Squash or merge into `main`. release-please will pick up the changes automatically.

## Releasing

Releases are fully automated once changes land on `main`. You do not manually edit versions anywhere.

### Normal release (patch or minor)

1. Commits accumulate on `main` via merged PRs.
2. [release-please](https://github.com/googleapis/release-please) automatically maintains an open **Release PR** titled `chore(main): release x.y.z`. It updates `CHANGELOG.md` and `version.txt` as new commits land.
3. When you're ready to ship, **merge the Release PR**.
4. Merging creates a git tag (e.g. `v0.2.0`) and a GitHub Release.
5. The tag triggers the `publish` workflow → approve the `nuget` environment deployment in GitHub Actions → package is pushed to NuGet.org.

### Pre-release (beta, rc)

release-please does not manage pre-release tags. Create them manually:

```bash
git tag v0.2.0-beta.1
git push origin v0.2.0-beta.1
```

Then approve the deployment in GitHub Actions as usual.

### Breaking changes (major bump)

Use a `!` suffix or a `BREAKING CHANGE:` footer in your commit message:

```
feat!: remove NearbyConnectionsEvents
```

release-please will propose a major version bump in the next Release PR.

## Commit messages

This project uses [Conventional Commits](https://www.conventionalcommits.org/). Commit messages determine how the version is bumped and what appears in the changelog.
Expand All @@ -13,16 +59,7 @@ This project uses [Conventional Commits](https://www.conventionalcommits.org/).

## Versioning

Versions are derived automatically from git tags at pack time via [MinVer](https://github.com/adamralph/minver). There is no version property in any project file.

The release workflow is:

1. Commits land on `main` following the conventional commit format above.
2. [release-please](https://github.com/googleapis/release-please) maintains an open Release PR that accumulates changes and proposes the next version.
3. Merging the Release PR creates a git tag (e.g. `v1.2.0`) and a GitHub Release with a generated changelog.
4. The `publish` workflow triggers on the tag, runs `dotnet pack`, and pushes the package to NuGet.org.

To release a pre-release version, manually create a tag in the format `v1.0.0-beta.1` — MinVer will produce the correct pre-release NuGet version from it.
Versions are derived automatically from git tags at pack time via [MinVer](https://github.com/adamralph/minver). There is no version property in any project file — the git tag is the single source of truth.

## Running tests

Expand Down
Loading