Skip to content
This repository
Browse code

[guides] Add info about CHANGELOGs to contributing guide

  • Loading branch information...
commit adf3ea373660c50c7bcead0f52ab2d63a25fc57e 1 parent 56627b6
Piotr Sarnacki authored August 11, 2012
25  guides/source/contributing_to_ruby_on_rails.textile
Source Rendered
@@ -359,6 +359,31 @@ Rails follows a simple set of coding style conventions.
359 359
 
360 360
 The above are guidelines -- please use your best judgment in using them.
361 361
 
  362
+h4. Updating the CHANGELOG
  363
+
  364
+The CHANGELOG is an important part of every release. It keeps the list of changes for every Rails version.
  365
+
  366
+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.
  367
+
  368
+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:
  369
+
  370
+<plain>
  371
+*   Summary of a change that briefly describes what was changed. You can use multiple
  372
+    lines and wrap them at around 80 characters. Code examples are ok, too, if needed:
  373
+
  374
+        class Foo
  375
+          def bar
  376
+            puts 'baz'
  377
+          end
  378
+        end
  379
+
  380
+    You can continue after the code example and you can attach issue number. GH#1234
  381
+
  382
+    * Your Name *
  383
+</plain>
  384
+
  385
+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.
  386
+
362 387
 h4. Sanity Check
363 388
 
364 389
 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 you’re 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 can’t convince one other developer of the beauty of your code, you’re unlikely to convince the core team either.

3 notes on commit adf3ea3

Xavier Noria
Owner
fxn commented on adf3ea3 August 11, 2012

Bravo!

Prem Sichanugrist
Collaborator

:+1:

Jeroen van Ingen

:+1: I like a clear description

Please sign in to comment.
Something went wrong with that request. Please try again.