Follow-up to #50507.
Since `brakeman` is now included in generated apps by default, it must
be installed before running Rails tests that invoke `bin/rails` for
generated apps.
This fixes CI failures such as:
```
Error:
AppGeneratorTest#test_app_update_does_not_change_app_name_when_app_name_is_hyphenated_name:
RuntimeError: Command failed with exit 1: yes | bin/rails app:update
test/generators/app_generator_test.rb:1304:in `system'
test/generators/app_generator_test.rb:1304:in `block (2 levels) in run_app_update'
test/generators/app_generator_test.rb:1304:in `block in run_app_update'
test/generators/app_generator_test.rb:1299:in `chdir'
test/generators/app_generator_test.rb:1299:in `run_app_update'
test/generators/app_generator_test.rb:430:in `test_app_update_does_not_change_app_name_when_app_name_is_hyphenated_name'
```
Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
- tweak opening paragraph to specifically mention that the Redis backing
a Cache should not be the Redis backing Active Job
- add code blocks to Redis::Distributed since it uses the class syntax
- expand on ways to point Cache at a Redis in initialization
- add an rdoc link for #fetch and a code block for `-amount`
* Add rubocop to new rails app generator
This setups a basic rubocop config for new rails apps using the `rubocop-rails-omakase` gem:
https://github.com/rails/rubocop-rails-omakase
It can be skipped with the `--skip-rubocop` flag.
Until now, Rails only droped compatibility with older
rubies on new majors, but I propose to change this policy
because it causes us to either keep compatibility with long
EOLed rubies or to bump the Rails major more often, and to
drop multiple Ruby versions at once when we bump the major.
In my opinion it's a bad alignments of incentives. And we'd
be much better to just drop support in new minors whenever they
go EOL (so 3 years).
Also Ruby being an upstream dependency, it's not even
a semver violation AFAICT.
Since Rails 7.2 isn't planned before a few months, we
can already drop Ruby 3.0 as it will be EOL in March.
Jonathan Hefner