Document default_options configuration in ActionMailer guide [ci skip]
Add extra documentation to the locale file.
edit of previous content
 explains how to add/override engine classes in the main rails app via
1) Class#class_eval
2) ActiveSupport::Concern
AM::Validation#validates: ability to pass custom exception to `:strict` option
Update list of finder methods
For adding non css/js files to precompile array
Fix #7191. Remove unnecessary transaction when assigning has_one associations.
add around_create callback documentation for ActiveModel::Callbacks
Document the namespacing of controller actions per this discussion:

https://github.com/rails/journey/issues/40
RouteSet: refactor internals

No need to build valid_conditions array.
We can get all the data in place.
Add 'X-Frame-Options' => 'SAMEORIGIN' and 'X-XSS-Protection' => '1; mode=block' CHANGELOG entry
Merge pull request #7286 from kennyj/fix_7191

Fix #7191. Remove unnecessary transaction when assigning has_one associations.
Remove the dependent_restrict_raises option.

It's not really a good idea to have this as a global config option. We
should allow people to specify the behaviour per association.

There will now be two new values:

* :dependent => :restrict_with_exception implements the current
  behaviour of :restrict. :restrict itself is deprecated in favour of
  :restrict_with_exception.
* :dependent => :restrict_with_error implements the new behaviour - it
  adds an error to the owner if there are dependent records present

See #4727 for the original discussion of this.
Clean up dependent option validation.

We don't need the complexity of to_sentence, and it shouldn't be a bang
method.
move dependency logic out of generated methods
Unprivatise all the things

Well, not all of them, but some of them.

I don't think there's much reason for these methods to be private.
DRY up handling of dependent option
remove some artifacts of dependent_restrict_raises that I missed
Merge pull request #7321 from bogdan/refactor_routes_set

RouteSet: refactor internals
Fix handling SCRIPT_NAME from within mounted engine's

When you mount your application at a path, for example /myapp, server
should set SCRIPT_NAME to /myapp. With such information, rails
application knows that it's mounted at /myapp path and it should generate
routes relative to that path.

Before this patch, rails handled SCRIPT_NAME correctly only for regular
apps, but it failed to do it for mounted engines. The solution was to
hardcode default_url_options[:script_name], which is not the best answer
- it will work only when application is mounted at a fixed path.

This patch fixes the situation by respecting original value of
SCRIPT_NAME when generating application's routes from engine and the
other way round - when you generate engine's routes from application.

This is done by using one of 2 pieces of information in env - current
SCRIPT_NAME or SCRIPT_NAME for a corresponding router. This is because
we have 2 cases to handle:

- generating engine's route from application: in this situation
  SCRIPT_NAME is basically SCRIPT_NAME set by the server and it
  indicates the place where application is mounted, so we can just pass
  it as :original_script_name in url_options. :original_script_name is
  used because if we use :script_name, router will ignore generating
  prefix for engine

- generating application's route from engine: in this situation we
  already lost information about the SCRIPT_NAME that server used. For
  example if application is mounted at /myapp and engine is mounted at
  /blog, at this point SCRIPT_NAME is equal /myapp/blog. Because of that
  we need to keep reference to /myapp SCRIPT_NAME by binding it to the
  current router. Later on we can extract it and use when generating url

Please note that starting from now you *should not* use
default_url_options[:script_name] explicitly if your server already
passes correct SCRIPT_NAME to rack env.

(closes #6933)