Revert removing BigDecimal.new in version 1.4 for very old version of Rails

[mrkn]

I decided to revert removing BigDecimal.new on bigdecimal 1.4 because very old version of Rails depends on it.

After releasing Ruby 2.6, I will release bigdecimal 1.5 without BigDecimal.new.

Reference

• http://koic.hatenablog.com/entry/exclude-rails-4-2-with-ruby-2-6
• Exclude Rails 4.2 + ruby-head build rails/webpacker#1825
• Exclude Rails 4.2 + ruby-head (2.6) build cucumber/cucumber-rails#400

[ioquatix]

Good idea. A lot of code depends on this. In theory, it shouldn't be removed until Ruby 3.0 because it's a backwards incompatible change?

[mrkn]

@ioquatix

it shouldn't be removed until Ruby 3.0 because it's a backwards incompatible change?

No, I don't think so because bigdecimal is just a standard library, but not ruby's core.

I have a plan to release version 1.5.0 with removing BigDecimal.new.
I'll import the latest version of bigdecimal in Ruby 2.7.

Users can control what version of bigdecimal is used by calling gem method or writing the version contraint in Gemfile.

[ioquatix]

If you are using semantic versioning you should not remove public interface in minor version bump. It should be 2.0.0 release to change or remove existing interface in backwards incompatible way.

[mrkn]

bigdecimal doesn’t employ semantic versioning.

[ioquatix]

What kind of versioning does it use?

[JonRowe]

An awful lot of people will use ~> versioning as semantic versioning is the norm in Ruby. I urge you to reconsider making a breaking change like this in a minor release, after all whats a version number? Releasing a 2.0.0 for a change like this in a core library has little in the way of downside and enormous upsides for the community.

[ioquatix]

All I can say, is that I agree that:

• We should be using semantic versioning.
• Removing a public method in a minor version bump is unexpected and broke stuff.
• Some level of compatibility is required going forward.

[mrkn]

I think it is good idea that version 2.0.0 follows version 1.4.0 because I can release bigdecimal 3.0.0 when CRuby 3.0 is released.

So, these are my decision:

• bigdecimal doesn't employ semantic versioning.
• The version after 1.4.0 is 2.0.0, and it will be released soon after CRuby version 2.6.
• The second digit of the version number is increased every year according to CRuby's version (e.g. bigdecimal 2.1.0 will be released with CRuby 2.7)
• The version 3.0.0 will be released with CRuby version 3.0.

[mrkn]

This issue was closed and isn't about versioning topic.
I don't want to continue to talk about versioning here, so I lock this issue.

[ioquatix]

I've created https://bugs.ruby-lang.org/issues/15456 for further discussion. I invite everyone to get involved.