More clarity on version selection
Thank you for the version selection chart. However, I'm finding it confusing for our case where we are upgrading to Ruby2.7.x and Rails 6.0.x (a common and modern stack)
Today, the version selection chart looks like:
| version | characteristics | Supported ruby version range |
|---|---|---|
| 3.0.0 | You can use BigDecimal with Ractor on Ruby 3.0 | 2.5 .. |
| 2.0.x | You cannot use BigDecimal.new and do subclassing | 2.4 .. |
| 1.4.x | BigDecimal.new and subclassing always prints warning. | 2.3 .. 2.6 |
| 1.3.5 | You can use BigDecimal.new and subclassing without warning | .. 2.5 |
The chart seems to indicate that the only compatible version of BigDecimal is 3.0. So, is 3.0 only compatible with Ruby3.0 or 2.5+? Further, upgrading past BigDecimal v1.3.5 runs us into lots of issue because lots of commonly used gems still use BigDecimal.new (eg, latest version of Stripe gem still does)
Even further, with 1.3.5, we're getting deprecation warnings with:
vendor/bundle/ruby/2.7.0/gems/activesupport-6.0.3.6/lib/active_support/core_ext/big_decimal/conversions.rb:9: warning: rb_check_safe_obj will be removed in Ruby 3.0
So, at the moment, it seems difficult to be in an upgraded state that works and also doesn't have any deprecation warnings.
@synth Very sorry too late response.
When you are using ruby 2.7.x, you can use bigdecimal 3.x or 2.0.x.
The reason why you want to use bigdecimal 1.3.5 is BigDecimal.new?
If so, does it works that you define BigDecimal.new method like below as your own?
def BigDecimal.new(*args)
BigDecimal(*args)
end
@mrkn Thanks for your response. Its been.. a while since I've looked at this. From our perspective, we're just trying to get rid of the deprecation warnings and have clarity on which is the best version to use and would rather not monkey patch BigDecimal.
Similar problem here. Trying to use BigDecimal.new with Ruby 3.1 and not sure what to choose. Also I don't understand the connection between ractor and BigDecimal.
For now, the monkeypatch proposed by @mrkn seems to work for me in order to get back the old behaviour.