From cce37a999920f31fe852d94fd6427f34a8994cf4 Mon Sep 17 00:00:00 2001 From: Minh Nguyen Cong Date: Tue, 14 Oct 2025 16:22:33 +0200 Subject: [PATCH 1/2] docs: Update CONTRIBUTING.md with commit message guidelines Clarify commit message guidelines and examples for scopes. --- CONTRIBUTING.md | 35 ++++++++++++++++++++++++----------- 1 file changed, 24 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index a4e23f0eb..37d61ef77 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 modifying or adding features for a specific part of the SDK, commits and pull requests should include a scope. The scope must be either `boxsdk` or `boxsdkgen`. 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(boxsdkgen): 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` 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(boxsdkgen): 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 From c4523ac26556f7ecc8352b4925df9bc59fa4abe7 Mon Sep 17 00:00:00 2001 From: Minh Nguyen Cong Date: Thu, 16 Oct 2025 15:16:22 +0200 Subject: [PATCH 2/2] Update contribution guidelines for commit scopes Clarify scope requirements for commits and pull requests in SDK. --- CONTRIBUTING.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 37d61ef77..a6bf255dd 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -49,7 +49,7 @@ Create a branch with a descriptive name, such as `add-search`. 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 modifying or adding features for a specific part of the SDK, commits and pull requests should include a scope. The scope must be either `boxsdk` or `boxsdkgen`. For general changes that don't affect a specific part (e.g., documentation updates, build configuration), the scope is optional. Examples: +**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(scope): short description @@ -60,7 +60,7 @@ longer description here if necessary. Examples with scope: - `feat(boxsdk): add new file upload feature` -- `fix(boxsdkgen): correct type definitions` +- `fix(boxsdk): correct type definitions` - `feat(boxsdk)!: remove deprecated endpoints` Examples without scope: @@ -68,7 +68,7 @@ Examples without scope: - `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` or `feat!: breaking change` for general changes). +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. @@ -90,7 +90,7 @@ In most cases, commits will be a `feat` or `fix`. Make sure to include the `!` i | Commit message | Release type | New version | | ------------------------------------------------------- | ------------------ | ----------- | | `feat(boxsdk)!: remove old files endpoints` | Major ("breaking") | `X+1.0.0` | -| `feat(boxsdkgen): add new file upload endpoint` | Minor ("feature") | `X.Y+1.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` |