You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+27-13Lines changed: 27 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,8 +16,8 @@ This project adheres to the [Box Open Code of Conduct](http://opensource.box.com
16
16
17
17
## How to contribute
18
18
19
-
***File an issue** - if you found a bug, want to request an enhancement, or want to implement something (bug fix or feature).
20
-
***Send a pull request** - if you want to contribute code. Please be sure to file an issue first.
19
+
-**File an issue** - if you found a bug, want to request an enhancement, or want to implement something (bug fix or feature).
20
+
-**Send a pull request** - if you want to contribute code. Please be sure to file an issue first.
21
21
22
22
## Pull request best practices
23
23
@@ -47,14 +47,28 @@ Create a branch with a descriptive name, such as `add-search`.
47
47
48
48
### Step 5: Push your feature branch to your fork
49
49
50
-
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:
50
+
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.
51
+
52
+
**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:
51
53
52
54
```
53
-
tag: short description
55
+
tag(scope): short description
56
+
tag: short description (when scope is not applicable)
57
+
54
58
longer description here if necessary.
55
59
```
56
60
57
-
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`).
61
+
Examples with scope:
62
+
-`feat(boxsdk): add new file upload feature`
63
+
-`fix(boxsdk): correct type definitions`
64
+
-`feat(boxsdk)!: remove deprecated endpoints`
65
+
66
+
Examples without scope:
67
+
-`docs: update README`
68
+
-`chore: update build configuration`
69
+
-`ci: fix GitHub Actions workflow`
70
+
71
+
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).
58
72
59
73
Shown below are examples of the release type that will be done based on a commit message.
60
74
@@ -73,14 +87,14 @@ The rules for commit types are:
73
87
74
88
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.
0 commit comments