diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a4e23f0eb..a6bf255dd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -47,15 +47,28 @@ Create a branch with a descriptive name, such as `add-search`. ### Step 5: Push your feature branch to your fork -We use [semantic-versioning](https://semver.org/) and the [conventional commit message format](https://www.conventionalcommits.org/en/v1.0.0/). Keep a separate feature branch for each issue you want to address. As you develop code, continue to push code to your remote feature branch. Example: +We use [semantic-versioning](https://semver.org/) and the [conventional commit message format](https://www.conventionalcommits.org/en/v1.0.0/). Keep a separate feature branch for each issue you want to address. As you develop code, continue to push code to your remote feature branch. + +**Important:** When editing the manual part of the SDK, commits and pull requests should include the `boxsdk` scope. For general changes that don't affect a specific part (e.g., documentation updates, build configuration), the scope is optional. Examples: ``` -tag: short description +tag(scope): short description +tag: short description (when scope is not applicable) longer description here if necessary. ``` -The message summary should be a one-sentence description of the change, and it must be 72 characters in length or shorter. For a list of tags, please [click here](https://github.com/commitizen/conventional-commit-types/blob/master/index.json). Note that you must include the `!` for breaking changes (e.g. `feat!: removed old apis`). +Examples with scope: +- `feat(boxsdk): add new file upload feature` +- `fix(boxsdk): correct type definitions` +- `feat(boxsdk)!: remove deprecated endpoints` + +Examples without scope: +- `docs: update README` +- `chore: update build configuration` +- `ci: fix GitHub Actions workflow` + +The message summary should be a one-sentence description of the change, and it must be 72 characters in length or shorter. For a list of tags, please [click here](https://github.com/commitizen/conventional-commit-types/blob/master/index.json). Note that you must include the `!` for breaking changes (e.g. `feat(boxsdk)!: removed old apis` for changes in manual part of the SDK or `feat!: breaking change` for general changes). Shown below are examples of the release type that will be done based on a commit message. @@ -74,14 +87,14 @@ The rules for commit types are: In most cases, commits will be a `feat` or `fix`. Make sure to include the `!` in the title if there are non-backwards-compatible changes in the commit. -| Commit message | Release type | New version | -| ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ----------- | -| `feat!: remove old files endpoints` | Major ("breaking") | `X+1.0.0` | -| `feat: add new file upload endpoint` | Minor ("feature") | `X.Y+1.0` | -| `fix: file streaming during download` | Patch ("fix") | `X.Y.Z+1` | -| `docs: document files api` | No release | `X.Y.Z` | -| `chore: remove commented code from file upload` | No release | `X.Y.Z` | -| `refactor: rename a variable (invisible change)` | No release | `X.Y.Z` | +| Commit message | Release type | New version | +| ------------------------------------------------------- | ------------------ | ----------- | +| `feat(boxsdk)!: remove old files endpoints` | Major ("breaking") | `X+1.0.0` | +| `feat(boxsdk): add new file upload endpoint` | Minor ("feature") | `X.Y+1.0` | +| `fix(boxsdk): file streaming during download` | Patch ("fix") | `X.Y.Z+1` | +| `docs: update README` | No release | `X.Y.Z` | +| `chore: update build configuration` | No release | `X.Y.Z` | +| `refactor(boxsdk): rename a variable (invisible change)`| No release | `X.Y.Z` | ### Step 6: Rebase