|
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,55 @@ 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. This summary will also be used as the changelog entry. |
| 313 | +- It must be short and self-explanatory for a reader who does not see the details of the full pull request description |
| 314 | +- It must not contain abbreviations, e.g. instead of `LQ` write `LiveQuery` |
| 315 | +- It must use the correct product and feature names as referenced in the documentation, e.g. instead of `Cloud Validator` use `Cloud Function validation` |
| 316 | +- In case of a breaking change, the summary must not contain duplicate information that is also in the [BREAKING CHANGE](#breaking-change) chapter of the pull request description. It must not contain a note that it is a breaking change, as this will be automatically flagged as such if the pull request description contains the BREAKING CHANGE chapter. |
| 317 | + |
| 318 | +For example: |
| 319 | + |
| 320 | +``` |
| 321 | +feat: add handle to door for easy opening |
| 322 | +``` |
| 323 | + |
| 324 | +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. |
| 325 | + |
| 326 | +### Breaking Change |
| 327 | + |
| 328 | +If a pull request contains a braking change, the description of the pull request must contain a special chapter at the bottom. |
| 329 | + |
| 330 | +The chapter consists of the phrase `BREAKING CHANGE`, capitalized, in a single line without any formatting. It must be followed by an empty line, then a short description of the breaking change, and ideally how the developer should address it. This chapter should contain more details focusing on the "breaking” aspect of the change, as it is intended to assist the developer in adapting their deployment. However, keep it concise, as it will also become part of the changelog entry. |
| 331 | +
|
| 332 | +For example: |
| 333 | +
|
| 334 | +``` |
| 335 | +Detailed pull request description... |
| 336 | +
|
| 337 | +BREAKING CHANGE |
| 338 | +
|
| 339 | +The door handle has be pulled up to open the door, not down. Adjust your habits accordingly by walking on your hands. |
| 340 | +``` |
| 341 | +
|
291 | 342 | ## Code of Conduct
|
292 | 343 |
|
293 | 344 | 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