|
19 | 19 | - [Wording Guideline](#wording-guideline)
|
20 | 20 | - [Parse Error](#parse-error)
|
21 | 21 | - [Parse Server Configuration](#parse-server-configuration)
|
| 22 | +- [Commit Message](#commit-message) |
| 23 | + - [Breaking Change](#breaking-change) |
22 | 24 | - [Code of Conduct](#code-of-conduct)
|
23 | 25 |
|
24 | 26 | ## Contributing
|
@@ -288,6 +290,47 @@ Introducing new [Parse Server configuration][config] parameters requires the fol
|
288 | 290 | 5. Add test cases to ensure the correct parameter value validation. Parse Server throws an error at launch if an invalid value is set for any configuration parameter.
|
289 | 291 | 6. Execute `npm run docs` to generate the documentation in the `/out` directory. Take a look at the documentation whether the description and formatting of the newly introduced parameters is satisfactory.
|
290 | 292 |
|
| 293 | +## Commit Message |
| 294 | + |
| 295 | +For release automation, the title of pull requests needs to be written in a defined syntax. We loosely follow the [Conventional Commits](https://www.conventionalcommits.org) specification, which defines this syntax: |
| 296 | + |
| 297 | +``` |
| 298 | +<type>: <summary> |
| 299 | +``` |
| 300 | + |
| 301 | +The _type_ is the category of change that is made, possible types are: |
| 302 | +- `feat` - add a new feature |
| 303 | +- `fix` - fix a bug |
| 304 | +- `refactor` - refactor code without impact on features or performance |
| 305 | +- `docs` - add or edit code comments, documentation, GitHub pages |
| 306 | +- `style` - edit code style |
| 307 | +- `build` - retry failing build and anything build process related |
| 308 | +- `perf` - performance optimization |
| 309 | +- `ci` - continuous integration |
| 310 | +- `test` - tests |
| 311 | + |
| 312 | +The _summary_ is a short change description in present tense, not capitalized, without period at the end. |
| 313 | + |
| 314 | +For example: |
| 315 | + |
| 316 | +``` |
| 317 | +feat: add handle to door for easy opening |
| 318 | +``` |
| 319 | + |
| 320 | +Currently, we are not making use of the commit _scope_, which would be written as `<type>(<scope>): <summary>`, that attributes a change to a specific part of the product. |
| 321 | + |
| 322 | +### Breaking Change |
| 323 | + |
| 324 | +If a pull request contains a braking change, the text of the pull request must contain the word `BREAKING CHANGE` capitalized as the _last, most bottom_ part of the text. It must be followed by an empty line, then a short description of the character of the breaking change, and ideally how the developer should address it. |
| 325 | + |
| 326 | +For example: |
| 327 | + |
| 328 | +``` |
| 329 | +BREAKING CHANGE |
| 330 | +
|
| 331 | +The door handle has be pulled up to open the door, not down. Adjust your habits accordingly by walking on your hands. |
| 332 | +``` |
| 333 | + |
291 | 334 | ## Code of Conduct
|
292 | 335 |
|
293 | 336 | This project adheres to the [Contributor Covenant Code of Conduct](https://github.com/parse-community/parse-server/blob/master/CODE_OF_CONDUCT.md). By participating, you are expected to honor this code.
|
|
0 commit comments