Roda 4 Planning

[jeremyevans]

Planning for Roda 4 has started! I expect to release Roda 4.0.0 in December 2027, with the last minor release of Roda 3 being 3.122.0 in November 2027. I currently expect to make the following high-level changes:

• The minimum Ruby version will be 3.2. Ruby is dropping ruby2_keywords support in Ruby 4.2, so at the very least, the minimum would be 3.0. However, Ruby 3.1 and 3.2 have some nice syntax features that I would like to take advantage of (hash value omission, anonymous rest and block args). This will be right before the Ruby 4.2 release, by which time Ruby 3.2 will have been out of support for almost 2 years. Note that Ruby 1.9 support will be dropped from Roda later this year, to prepare for the use of keyword arguments. It's possible support for additional Ruby versions will be dropped before the release of Roda 4, if it is necessary or significantly simplifies the upgrade planning.

• The minimum Rack version will be 3.0. Unless something changes, Rack 2.2 will be fully unsupported sometime in 2027. This will allow a simplifying a significant amount of Roda code.

• plain_hash_response_headers plugin behavior will be the default. Potentially we can add a plugin to support Rack::Headers for response headers (to support use of non-lowercase header keys), if a user requests it.

• Methods and plugins that currently accept option hashes may switch to accepting keyword arguments (decision on a case-by-case basis)

• When creating methods from blocks (such as for the route method), Roda will assume the block has the correct arity and will not make adjustments to fix arity problems (the behavior if you specify the check_arity: false app option).

• Support for the old dispatch API will be removed (this has been warned for many versions)

• Passing arguments to plugins that don't use them will be an error (also warned for many versions).

• Some plugins will be removed:

  • static (no need, just use the public plugin or Rack::Static middleware)

  • csrf (route_csrf plugin is superior and has been recommended for a long time)

  • route_block_args (too invasive for too little benefit)

  • delay_build (now a no-op)

• Some plugin behaivor will be modified:

  • assets: will no longer automatically compress assets, compression will need to be configured

  • sessions: will no longer support upgrading Rack sessions (the conversion doesn't work with current rack-session code) and will no longer support compressed sessions

  • mail: The terminal: true option will become the only behavior

  • middleware: the :next_if_not_found option will become the default

  • path: The :path_class_by_name option will no longer be supported

  • json: json_result_classes class method will be removed

  • capture_erb: returns: :buffer will become the only behavior

There will likely be significant additional changes. I plan on doing a line-by-line review of all code over the next few months and will likely decide to deprecate additional parts while performing that review. I'll be opening additional discussion topics for additional planned deprecations.

I welcome community feedback on these plans. If there is something I plan to deprecate that you rely on, speak up, providing details on why you need the feature. If there is something you don't like that you would like to see deprecated, advocate for it, explaining why you think we should deprecate it. One of the reasons for this early announcement (16 months before planned release) is to allow plenty of time for community feedback.

Best,
Jeremy

[mensfeld]

All good from my side (Karafka). Thank you for planning ahead 🙏