Merge branch 'master' into habtm

* master:
  we can define callbacks without a builder instance
  push methods that don't depend on the instance to the class
  get the name from the reflection
  cache the name and options on the stack
  decouple belongs_to callback definition from the builder instance.
  add_before_destroy_callbacks doesn't depend on the instance, so push it to the class.
  valid_options doesn't depend on the instance, so push it to the class
  use the information on the reflection to determine whether callbacks should be added
  Running all isolated test for actionview
  association builder is no longer needed for counter cache, so remove it
  push constructable? on to the reflection
  Adds the Rails maintenance policy to the Guides
  name is on the reflection, so just use the reflection
  decouple define_callback from the instance
  Added activemodel as a explicit dependency
  unify `Fixes` notes in AR changelog. [ci skip].
  improving `reload` doc wording. #12418 [ci skip]
  Update AR reload doc for the case of manually set primary key attribute [ci skip]

3 files changed, 70 insertions, 0 deletions

diff --git a/guides/CHANGELOG.md b/guides/CHANGELOG.md
index afa695d445..38e407b198 100644
--- a/guides/CHANGELOG.md
+++ b/guides/CHANGELOG.md
@@ -2,4 +2,8 @@
 
     *Sıtkı Bağdat*
 
+*   Added the Rails maintenance policy to the guides.
+
+    *Matias Korhonen*
+
 Please check [4-0-stable](https://github.com/rails/rails/blob/4-0-stable/guides/CHANGELOG.md) for previous changes.
diff --git a/guides/source/documents.yaml b/guides/source/documents.yaml
index 1b16f4e516..1bf9ff95e1 100644
--- a/guides/source/documents.yaml
+++ b/guides/source/documents.yaml
@@ -150,6 +150,13 @@
       url: ruby_on_rails_guides_guidelines.html
       description: This guide documents the Ruby on Rails guides guidelines.
 -
+  name: Maintenance Policy
+  documents:
+    -
+      name: Maintenance Policy
+      url: maintenance_policy.html
+      description: What versions of Ruby on Rails are currently supported, and when to expect new versions.
+-
   name: Release Notes
   documents:
     -
diff --git a/guides/source/maintenance_policy.md b/guides/source/maintenance_policy.md
new file mode 100644
index 0000000000..354b1121aa
--- /dev/null
+++ b/guides/source/maintenance_policy.md
@@ -0,0 +1,59 @@
+Maintenance policy for Ruby on Rails
+====================================
+
+Since the most recent patch releases there has been some confusion about what
+versions of Ruby on Rails are currently supported, and when people
+can expect new versions. Our maintenance policy is as follows.
+
+Support of the Rails framework is divided into four groups: New features, bug
+fixes, security issues, and severe security issues. They are handled as
+follows, all versions in x.y.z format:
+
+New Features
+------------
+
+New Features are only added to the master branch and will not be made available
+in point releases.
+
+Bug fixes
+---------
+
+Only the latest release series will receive bug fixes. When enough bugs are
+fixed and its deemed worthy to release a new gem, this is the branch it happens
+from.
+
+**Currently included series:** 4.0.z
+
+Security issues:
+----------------
+
+The current release series and the next most recent one will receive patches
+and new versions in case of a security issue.
+
+These releases are created by taking the last released version, applying the
+security patches, and releasing. Those patches are then applied to the end of
+the x-y-stable branch. For example, a theoretical 1.2.3 security release would
+be built from 1.2.2, and then added to the end of 1-2-stable. This means that
+security releases are easy to upgrade to if you're running the latest version
+of Rails.
+
+**Currently included series:** 4.0.z, 3.2.z
+
+Severe security issues:
+-----------------------
+
+For severe security issues we will provide new versions as above, and also the
+last major release series will receive patches and new versions. The
+classification of the security issue is judged by the core team.
+
+**Currently included series:** 4.0.z, 3.2.z
+
+Unsupported Release Series
+--------------------------
+
+When a release series is no longer supported, it's your own responsibility to
+deal with bugs and security issues. We may provide back-ports of the fixes and
+publish them to git, however there will be no new versions released. If you are
+not comfortable maintaining your own versions, you should upgrade to a
+supported version.
+