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.
* Make Sprockets more optional, offer Propshaft as alternative
* Whups, local reference
* No longer used
* Spacing
* Need explicit sprockets-rails inclusion now
* Manually require the sprockets railtie
* Don't need these changes right now
* Kick off another build
* Fix tests
* DRY up test
* Require railtie when using sprockets
* Introduce option to skip asset pipeline
* No longer relevant
* Always have to return
* Gone
* Add helper for skip_sprockets?
* Fix guard statement
* Use latest gems
* Include propshaft
* fix tests for #43261 (#43277)
* help fix tests for #43261
skip_sprockets? should not be called on options
:skip_sprockets is no longer a value in the option hash, so
skip_sprockets? should not be called on it
move --asset-pipeline to shared generator
skip_sprockets? is defined on app_base, and used in the plugin
generator to determine whether to add the engine's assets to the dummy
sprockets manifest, so I believe it makes sense to include in both
generators
Because of this change, I also changed the shared test back to testing
against non-sprockets
add skip_sprockets to Gemfile template vars
Mocking skip_sprockets? in app_base generator
fix more generator tests
* use skip_sprockets? everywhere
* Use latest propshaft
* Update `AssetUrlHelper` docs to list both asset pipeline gems (#43328)
* Update to latest Propshaft
* Bump Propshaft again
* Ask for latest
* Use latest propshaft
Co-authored-by: Hartley McGuire <skipkayhil@gmail.com>
Co-authored-by: Richard Macklin <1863540+rmacklin@users.noreply.github.com>
Generally followed the pattern for https://github.com/rails/rails/pull/32034
* Removes needless CI configs for 2.4
* Targets 2.5 in rubocop
* Updates existing CHANGELOG entries for fewer merge conflicts
* Removes Hash#slice extension as that's inlined on Ruby 2.5.
* Removes the need for send on define_method in MethodCallAssertions.
Fixes 4d157ea8c1
Without any specification about the version of sprockets-rails, running a
`bundle install` on a brand new app might result in sprockets 0.0.1 being
installed.
However, the minimum requirement is sprockets-rails 2 (see https://github.com/rails/rails/pull/17752/files)
This patch removes the tasks doc:app, doc:rails, and doc:guides.
In our experience applications do not generate APIs using doc:app.
Methods may be certainly documented for maintainers, annotated
with YARD tags, etc. but that is intended to be read with the
source code, not in a separate website. Then, teams also have
typically selected topics written down in Markdown files, or in
a GitHub wiki... that kind of thing.
If a team absolutely needs to generate application documentation
for internal purposes, they can still easily write their own task.
Regarding doc:rails and doc:guides, we live in 2015. We are used
to go to online docs all the time. If you really want access to the
API offline RubyGems generates it for every Rails component unless
you tell it not to, and you can checkout the Rails source code to
read the guides as Markdown, or download them for a Kindle reader.
All in all, maintaining this code does not seem to be worthwhile
anymore.
As a consequence of this, guides (+3 MB uncompressed) won't be
distributed with the rails gem anymore. Of course, guides and API
are going to be still part of releases, since documentation is
maintained alongside code and tests.
Also, time permitting, this will allow us to experiment with novel
ways to generate documentation in the Rails docs server, since
right now we were constrained by being able to generate them in
the user's environment.
Revert "Bump bundler dep to 1.3.0.pre.4+ to introduce 'bundle binstubs <gem>'"
This reverts commit e00b8ecf1ad8984b760f12e61247820613aec4ee.
Revert "Use bundler --pre for travis builds"
This reverts commit 4d240ec20a70122b7e69c790a37d2be14e1ff038.
