1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Merge pull request #19732 from wazery/patch-2

[ci skip] Update contributing guide
This commit is contained in:
Kasper Timm Hansen 2015-04-12 16:32:00 +02:00
commit efaec3dd63

View file

@ -355,9 +355,9 @@ $ RUBYOPT=-W0 bundle exec rake test
The CHANGELOG is an important part of every release. It keeps the list of changes for every Rails version. The CHANGELOG is an important part of every release. It keeps the list of changes for every Rails version.
You should add an entry to the CHANGELOG of the framework that you modified if you're adding or removing a feature, committing a bug fix or adding deprecation notices. Refactorings and documentation changes generally should not go to the CHANGELOG. You should add an entry **to the top** of the CHANGELOG of the framework that you modified if you're adding or removing a feature, committing a bug fix or adding deprecation notices. Refactorings and documentation changes generally should not go to the CHANGELOG.
A CHANGELOG entry should summarize what was changed and should end with author's name and it should go on top of a CHANGELOG. You can use multiple lines if you need more space and you can attach code examples indented with 4 spaces. If a change is related to a specific issue, you should attach the issue's number. Here is an example CHANGELOG entry: A CHANGELOG entry should summarize what was changed and should end with the author's name. You can use multiple lines if you need more space and you can attach code examples indented with 4 spaces. If a change is related to a specific issue, you should attach the issue's number. Here is an example CHANGELOG entry:
``` ```
* Summary of a change that briefly describes what was changed. You can use multiple * Summary of a change that briefly describes what was changed. You can use multiple