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

[guides] Add info about CHANGELOGs to contributing guide

This commit is contained in:
Piotr Sarnacki 2012-08-11 12:43:55 +02:00
parent 56627b619c
commit adf3ea3736

View file

@ -359,6 +359,31 @@ Rails follows a simple set of coding style conventions.
The above are guidelines -- please use your best judgment in using them. The above are guidelines -- please use your best judgment in using them.
h4. Updating the CHANGELOG
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, commiting 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. 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 issue's number. Here is an example CHANGELOG entry:
<plain>
* Summary of a change that briefly describes what was changed. You can use multiple
lines and wrap them at around 80 characters. Code examples are ok, too, if needed:
class Foo
def bar
puts 'baz'
end
end
You can continue after the code example and you can attach issue number. GH#1234
* Your Name *
</plain>
Your name can be added directly after the last word if you don't provide any code examples or don't need multiple paragraphs. Otherwise, it's best to make as a new paragraph.
h4. Sanity Check h4. Sanity Check
You should not be the only person who looks at the code before you submit it. You know at least one other Rails developer, right? Show them what youre doing and ask for feedback. Doing this in private before you push a patch out publicly is the “smoke test” for a patch: if you cant convince one other developer of the beauty of your code, youre unlikely to convince the core team either. You should not be the only person who looks at the code before you submit it. You know at least one other Rails developer, right? Show them what youre doing and ask for feedback. Doing this in private before you push a patch out publicly is the “smoke test” for a patch: if you cant convince one other developer of the beauty of your code, youre unlikely to convince the core team either.