diff options
author | Aaron Patterson <aaron.patterson@gmail.com> | 2013-10-02 15:28:59 -0700 |
---|---|---|
committer | Aaron Patterson <aaron.patterson@gmail.com> | 2013-10-02 15:28:59 -0700 |
commit | 7a38eae0075b4f38462be267fa80a4ff366fdd00 (patch) | |
tree | 60090e23ea084c1446cdeae5d56b06a9fb611b4e /guides/source | |
parent | 0091808a081e85d4f44631984fa8a54ddf345868 (diff) | |
parent | b86a4965b8532286430b7cd9b359a2574d745b92 (diff) | |
download | rails-7a38eae0075b4f38462be267fa80a4ff366fdd00.tar.gz rails-7a38eae0075b4f38462be267fa80a4ff366fdd00.tar.bz2 rails-7a38eae0075b4f38462be267fa80a4ff366fdd00.zip |
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]
Diffstat (limited to 'guides/source')
-rw-r--r-- | guides/source/documents.yaml | 7 | ||||
-rw-r--r-- | guides/source/maintenance_policy.md | 59 |
2 files changed, 66 insertions, 0 deletions
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. + |