Summary
Should we deprecate support for older Rails and Ruby versions to simplify maintenance and leverage modern framework features?
Context
While implementing callback support and fixing Rails 7.1+ compatibility issues (#310), I've had to add version-specific conditionals throughout the codebase to accommodate breaking changes across Rails versions. This raises the question: is it time to drop support for older versions?
Current Support Matrix
Based on .github/workflows/ci.yml:
Ruby Versions:
- 2.5 (EOL: March 2021)
- 2.6 (EOL: March 2022)
- 2.7 (EOL: March 2023)
- 3.0 (EOL: March 2024)
- 3.1 (Security maintenance until March 2025)
- 3.2 (Active)
Rails Versions:
- 5.2 (EOL: June 2022)
- 6.0 (EOL: June 2023)
- 7.0 (Active, security fixes until June 2025)
- 7.1 (Active, security fixes until October 2026)
Maintenance Burden Examples
Recent fixes required version-specific code in multiple locations:
- Migration API (test/test_helper.rb):
- Rails < 5.2: ActiveRecord::Migrator.migrate
- Rails 5.2-6.0: ActiveRecord::MigrationContext.new(path).migrate
- Rails 6.0-7.0: ActiveRecord::MigrationContext.new(path, SchemaMigration).migrate
- Rails 7.1+: Back to ActiveRecord::MigrationContext.new(path).migrate
- Exception Handling (test/dummy/config/environments/test.rb):
- Rails < 7.1: show_exceptions = false
- Rails 7.1+: show_exceptions = :none
- Callback Implementation (lib/wicked/controller/concerns/render_redirect.rb):
- Ruby 2.x: Cannot use anonymous block forwarding (&)
- Ruby 3+: Can use & syntax
Proposal
Consider deprecating support for:
Ruby versions: 2.5, 2.6, 2.7, 3.0
- Keep: Ruby 3.1+ only
Rails versions: 5.2, 6.0 (past EOL)
- Keep: Rails 7.0+ only
Benefits
✅ Reduce version-specific conditionals and technical debt
✅ Leverage modern Ruby features (pattern matching, endless methods, block forwarding)
✅ Simplify CI matrix
✅ Focus testing efforts on actively maintained versions
✅ Easier onboarding for new contributors
Considerations
⚠️ Breaking change for users on legacy Rails/Ruby versions
⚠️ Would require major version bump (3.0.0)
⚠️ May impact adoption for teams with legacy applications
Summary
Should we deprecate support for older Rails and Ruby versions to simplify maintenance and leverage modern framework features?
Context
While implementing callback support and fixing Rails 7.1+ compatibility issues (#310), I've had to add version-specific conditionals throughout the codebase to accommodate breaking changes across Rails versions. This raises the question: is it time to drop support for older versions?
Current Support Matrix
Based on .github/workflows/ci.yml:
Ruby Versions:
Rails Versions:
Maintenance Burden Examples
Recent fixes required version-specific code in multiple locations:
Proposal
Consider deprecating support for:
Ruby versions: 2.5, 2.6, 2.7, 3.0
Rails versions: 5.2, 6.0 (past EOL)
Benefits
✅ Reduce version-specific conditionals and technical debt
✅ Leverage modern Ruby features (pattern matching, endless methods, block forwarding)
✅ Simplify CI matrix
✅ Focus testing efforts on actively maintained versions
✅ Easier onboarding for new contributors
Considerations