Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Better commit message for breaking changes. #16846

Closed
wants to merge 2 commits into from
Closed

Better commit message for breaking changes. #16846

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4b36f14
doc: request better commit message for breaking changes.
MatonAnthony Nov 6, 2017
a0eb036
doc: fix grammar + add a paragraph regarding breaking change wiki pages
MatonAnthony Nov 6, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -334,6 +334,14 @@ use `Refs:`.
- `Refs: http://eslint.org/docs/rules/space-in-parens.html`
- `Refs: https://github.com/nodejs/node/pull/3615`

5. If your commit introduces a breaking change (`semver-major`), it should contain
an explanation about the reason of the breaking change, which situation would trigger
the breaking change and what is the exact change.

Breaking changes will be listed in the wiki with the aim to make upgrading easier.
Please have a look at [Breaking Changes](https://github.com/nodejs/node/wiki/Breaking-changes-between-v4-LTS-and-v6-LTS)
for the level of detail that's suitable.

Sample complete commit message:

```txt
Expand Down Expand Up @@ -625,6 +633,7 @@ Focus first on the most significant aspects of the change:
1. Does this change make sense for Node.js?
2. Does this change make Node.js better, even if only incrementally?
3. Are there clear bugs or larger scale issues that need attending to?
4. Is the commit message readable and correct? If it contains a breaking change is it clear enough?

When changes are necessary, *request* them, do not *demand* them, and do not
assume that the submitter already knows how to add a test or run a benchmark.
Expand Down