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.
There are valid use cases for running SQLite in production, however it must be done
with care, so instead of a warning most users won't see anyway, it's preferable to
leave the configuration commented out to force them to think about having the database
on a persistent volume etc.
Co-Authored-By: Jacopo Beschi <beschi.jacopo@gmail.com>
This fixes the following error for the guides build:
```
Traceback (most recent call last):
13: from bug_report_templates/action_controller.rb:5:in `<main>'
12: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/inline.rb:42:in `gemfile'
11: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler.rb:403:in `with_unbundled_env'
10: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler.rb:649:in `with_env'
9: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler.rb:403:in `block in with_unbundled_env'
8: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/inline.rb:51:in `block in gemfile'
7: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/settings.rb:142:in `temporary'
6: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/inline.rb:66:in `block (2 levels) in gemfile'
5: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/runtime.rb:24:in `setup'
4: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/runtime.rb:24:in `map'
3: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/spec_set.rb:165:in `each'
2: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/spec_set.rb:165:in `each'
1: from /usr/local/bundle/gems/bundler-2.4.22/lib/bundler/runtime.rb:25:in `block in setup'
/usr/local/bundle/gems/bundler-2.4.22/lib/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated psych 5.1.1.1, but your Gemfile requires psych 5.1.2. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
```
This is similar to #45052. Eventually, this should be fixed permanently
by either rubygems/rubygems#5529 or rubygems/rubygems#5535.
Follow-up to #46530.
The dynamically generated `url_helpers` module is an
`ActiveSupport::Concern`. Therefore, when it is included directly in
another `ActiveSupport::Concern`, its `included` block is deferred until
the latter concern is itself included elsewhere. Thus, in that case,
the call to `base._routes` in `def self.included(base)` will raise
`NoMethodError` because the `included` block will not yet have defined
the `_routes` method.
This commit prevents the error by first checking if `base` responds to
`_routes`.
Fix: https://github.com/rails/rails/issues/50368
When called on a scope it would go through the default scoping
delegator that applies a default scope, which make no sense.
I checked https://github.com/rails/rails/issues/50327 and noticed that
clear API docs are needed. Some developers are using these methods
incorrectly, thinking they're only for Active Record Relation, but they
actually work with Enumerable.
Jean Boussier