aboutsummaryrefslogtreecommitdiffstats
path: root/guides
diff options
context:
space:
mode:
authorPiotr Sarnacki <drogus@gmail.com>2012-05-23 23:08:39 -0700
committerPiotr Sarnacki <drogus@gmail.com>2012-05-23 23:08:39 -0700
commit95c49f2445aca2f974b6886193627379a7c4f7bf (patch)
tree6625f15ddefd346f01e47e05dbcdb1f7709be9a4 /guides
parent880481a355e0017c43d6ff14b2d1a657548d06bf (diff)
parentc97fb889a6db6c661853ce0612791a26524e7c50 (diff)
downloadrails-95c49f2445aca2f974b6886193627379a7c4f7bf.tar.gz
rails-95c49f2445aca2f974b6886193627379a7c4f7bf.tar.bz2
rails-95c49f2445aca2f974b6886193627379a7c4f7bf.zip
Merge pull request #6447 from chancancode/add_backporting_instructions_to_contrib_guides
Added instructions for backporting changes to guides.
Diffstat (limited to 'guides')
-rw-r--r--guides/source/contributing_to_ruby_on_rails.textile29
1 files changed, 29 insertions, 0 deletions
diff --git a/guides/source/contributing_to_ruby_on_rails.textile b/guides/source/contributing_to_ruby_on_rails.textile
index a2254a550c..72cdea885f 100644
--- a/guides/source/contributing_to_ruby_on_rails.textile
+++ b/guides/source/contributing_to_ruby_on_rails.textile
@@ -430,6 +430,35 @@ h4. Iterate as Necessary
It’s entirely possible that the feedback you get will suggest changes. Don’t get discouraged: the whole point of contributing to an active open source project is to tap into community knowledge. If people are encouraging you to tweak your code, then it’s worth making the tweaks and resubmitting. If the feedback is that your code doesn’t belong in the core, you might still think about releasing it as a gem.
+h4. Backporting
+
+Changes that are merged into master are intended for the next major release of Rails. Sometimes, it might be beneficial for your changes to propagate back to the maintenance releases for older stable branches. Generally, security fixes and bug fixes are good candidates for a backport, while new features and patches that introduce a change in behavior will not be accepted. When in doubt, it is best to consult a rails team member before backporting your changes to avoid wasted effort.
+
+For simple fixes, the easiest way to backport your change is to "extract a diff from your changes in master and apply them to the target branch":http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git.
+
+First make sure your changes are the only difference between your current branch and master:
+
+<shell>
+$ git log master..HEAD
+</shell>
+
+Then extract the diff:
+
+<shell>
+$ git format-patch master --stdout > ~/my_changes.patch
+</shell>
+
+Switch over to the target branch and apply your changes:
+
+<shell>
+$ git checkout -b my_backport_branch 3-2-stable
+$ git apply ~/my_changes.patch
+</shell>
+
+This works well for simple changes. However, if your changes are complicated or if the code in master has deviated significantly from your target branch, it might require more work on your part. The difficulty of a backport varies greatly from case to case, and sometimes it is simply not worth the effort.
+
+Once you have resolved all conflicts and made sure all the tests are passing, push your changes and open a separate pull request for your backport. It is also worth noting that older branches might have a different set of build targets than master. When possible, it is best to first test your backport locally against the ruby versions listed in +.travis.yml+ before submitting your pull request.
+
And then ... think about your next contribution!
h3. Rails Contributors