### Summary
In a Rails application using Ruby 2.6.0-dev, when running `bin/rails g migration`
with `RUBYOPT=-w`, an ERB deprecation warnings will be displayed.
```console
% ruby -v
ruby 2.6.0dev (2018-03-03 trunk 62644) [x86_64-darwin17]
% bin/rails -v
Rails 6.0.0.alpha
% RUBYOPT=-w bin/rails g migration create_foos
(snip)
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing eoutvar with the 4th argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, eoutvar: ...)
instead.
create db/migrate/20180304002144_create_foos.rb
```
This PR suppresses the above deprecation warnings in Ruby 2.6.0-dev.
This warning is due to the interface of `ERB.new` will change from Ruby 2.6.
> Add :trim_mode and :eoutvar keyword arguments to ERB.new.
> Now non-keyword arguments other than first one are softly deprecated
> and will be removed when Ruby 2.5 becomes EOL. [Feature #14256]
2311087b68/NEWS (stdlib-updates-outstanding-ones-only)
The following addresses are related Ruby's commit.
https://github.com/ruby/ruby/commit/cc777d0
Also this PR will change `ERB.new` used in `tasks/release.rb`.
### Other Information
This PR uses `ERB.version` to switch `ERB.new` interface. Because Rails 6
supports multiple Ruby versions (Ruby 2.4.1 or higher), it need to
use the appropriate interface.
Using `ERB.version` instead of `RUBY_VERSON` is based on the following patch.
https://github.com/ruby/ruby/pull/1826
This patch is built into Ruby.
40db89c093
Basically revises the release flow to:
* Update the version in RAILS_VERSION + rake changelog:header
* Run rake all:verify (click around in the booted app)
* If that checks out, run rake release.
Note: this commit looks super weird becuase git. I'm moving the entire
NPM section to the part where we actually push the gems/npm package for
the reasons below. That's not how the git diff looks though.
When we release Rails we run `rake prep_release` which calls
`update_versions`. This was updating the NPM version as well. But when we
would later run `rake install` to test the installed gem
`update_versions` gets called again which causes the install to fail
because NPM sees the version is the same as the last run and refuses to
continue. If you forget to stash this will then cause the push to
RubyGems to fail because `update_versions` is called again and then NPM
will not continue because it thinks the version hasn't been changed even
though it has.
The correct solution would be to not update the NPM verion if it matches
the version already in the file but after an hour I could not find a
simple way to use NPM to read the current version. Honestly that's not
the best way to do it either because say you forget to update something
else and then the script thinks it's already been updated.
With that in mind I think the best solution is to not update the NPM
version until right before we are going to push to NPM because then that
won't cause the push to RubyGems to fail.
Dear Active Resource,
It's not that I hate you or anything, but you didn't get much attention lately. There're so many alternatives out there, and I think people have made their choice to use them than you. I think it's time for you to have a big rest, peacefully in this Git repository.
I will miss you,
@sikachu.
