diff options
| author | Matthew Draper <matthew@trebex.net> | 2017-03-18 07:30:30 +1030 |
|---|---|---|
| committer | Matthew Draper <matthew@trebex.net> | 2017-03-18 07:30:30 +1030 |
| commit | 4183ee882055f997fe61804ba43ee4c168b2477c (patch) | |
| tree | cb1812aa43ba598a89540f9eca1cdd45c88fb4b3 /guides/source/3_0_release_notes.md | |
| parent | 7413be0d31ec7eacc6f93e26546cb02ac6db73ca (diff) | |
| download | rails-4183ee882055f997fe61804ba43ee4c168b2477c.tar.gz rails-4183ee882055f997fe61804ba43ee4c168b2477c.tar.bz2 rails-4183ee882055f997fe61804ba43ee4c168b2477c.zip | |
Track the version-compatible config settings inside railties
Instead of forcing new applications to carry an initializer that just
switches things to what their default "should" be, we can handle it
internally.
The initializer is then only used by upgraders: it shows what the new
default would be (commented out), while their upgraded application
continues to operate as it did before.
Under this model, a multiply-upgraded application could accumulate
several new_framework_defaults_*.rb files, for each release series it
has traversed. A given release series only needs to generate the latest,
though, because we don't support `rails app:upgrade` while skipping
releases.
Diffstat (limited to 'guides/source/3_0_release_notes.md')
0 files changed, 0 insertions, 0 deletions