Issue #22241 has been updated by byroot (Jean Boussier). `quirks_mode` hasn't been a valid argument for years. I can't even tell you what its behavior may have been. Any code that pass `quirks_mode` should stop passing that argument, and it won't cause any compatibility. As for the positional `limit` argument, this one I'm open to put it back, but the form `JSON.dump(obj, max_nesting: <limit>)` has been supported forever as well. ---------------------------------------- Bug #22241: Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments https://bugs.ruby-lang.org/issues/22241#change-118508 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: byroot (Jean Boussier) * Target version: 4.1 * ruby -v: f51515f39a13223ce784eb3412c1f83a8a3960a4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- JSON 3.0.0.rc1 removes two previously accepted arguments without a deprecation period: ```ruby JSON.dump(object, io, 0) JSON.parse(source, quirks_mode: true) ``` The first call now raises `TypeError` because the third positional argument is treated as an options hash. The second raises `ArgumentError` because `quirks_mode` is no longer recognized. Neither usage produces a deprecation warning with JSON 2.21.2, even with warnings enabled: ```ruby Warning[:deprecated] = true ``` This currently breaks downstream test suites. RDoc used the third `JSON.dump` argument when generating its JSON index, while `json-schema` 5.1.0 passes `quirks_mode: true`, causing RBS schema tests in the Ruby repository to fail. Because JSON is a default gem, downstream projects cannot always avoid the breakage by pinning an older version, especially when testing against Ruby head. Could JSON 3.0 continue accepting these arguments for compatibility? `quirks_mode` can presumably be accepted and ignored now that top-level scalar values are parsed by default. The positional `limit` argument could similarly remain supported until it has gone through a deprecation cycle. -- https://bugs.ruby-lang.org/

Issue #22241 has been updated by byroot (Jean Boussier).

Could JSON 3.0 continue accepting these arguments for compatibility?

I'd prefer if Ruby kept using the `2.x-stable` branch until ready: https://github.com/ruby/json/tree/2.x-stable ---------------------------------------- Bug #22241: Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments https://bugs.ruby-lang.org/issues/22241#change-118510 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: byroot (Jean Boussier) * Target version: 4.1 * ruby -v: f51515f39a13223ce784eb3412c1f83a8a3960a4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- JSON 3.0.0.rc1 removes two previously accepted arguments without a deprecation period: ```ruby JSON.dump(object, io, 0) JSON.parse(source, quirks_mode: true) ``` The first call now raises `TypeError` because the third positional argument is treated as an options hash. The second raises `ArgumentError` because `quirks_mode` is no longer recognized. Neither usage produces a deprecation warning with JSON 2.21.2, even with warnings enabled: ```ruby Warning[:deprecated] = true ``` This currently breaks downstream test suites. RDoc used the third `JSON.dump` argument when generating its JSON index, while `json-schema` 5.1.0 passes `quirks_mode: true`, causing RBS schema tests in the Ruby repository to fail. Because JSON is a default gem, downstream projects cannot always avoid the breakage by pinning an older version, especially when testing against Ruby head. Could JSON 3.0 continue accepting these arguments for compatibility? `quirks_mode` can presumably be accepted and ignored now that top-level scalar values are parsed by default. The positional `limit` argument could similarly remain supported until it has gone through a deprecation cycle. -- https://bugs.ruby-lang.org/

Issue #22241 has been updated by byroot (Jean Boussier).

but also think it was problematic that the users had no chance to be noticed about them.

Well, I was planning to add deprecation for them in a new 2.x release soon. Right now it's a RC1, nobody is installing it without explicitly asking for it, except for ruby/ruby.

Not to the upstream?

Erf, I was tired, sorry: https://github.com/voxpupuli/json-schema/pull/578 I also started https://github.com/ruby/rbs/pull/3081 ---------------------------------------- Bug #22241: Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments https://bugs.ruby-lang.org/issues/22241#change-118513 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: byroot (Jean Boussier) * Target version: 4.1 * ruby -v: f51515f39a13223ce784eb3412c1f83a8a3960a4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- JSON 3.0.0.rc1 removes two previously accepted arguments without a deprecation period: ```ruby JSON.dump(object, io, 0) JSON.parse(source, quirks_mode: true) ``` The first call now raises `TypeError` because the third positional argument is treated as an options hash. The second raises `ArgumentError` because `quirks_mode` is no longer recognized. Neither usage produces a deprecation warning with JSON 2.21.2, even with warnings enabled: ```ruby Warning[:deprecated] = true ``` This currently breaks downstream test suites. RDoc used the third `JSON.dump` argument when generating its JSON index, while `json-schema` 5.1.0 passes `quirks_mode: true`, causing RBS schema tests in the Ruby repository to fail. Because JSON is a default gem, downstream projects cannot always avoid the breakage by pinning an older version, especially when testing against Ruby head. Could JSON 3.0 continue accepting these arguments for compatibility? `quirks_mode` can presumably be accepted and ignored now that top-level scalar values are parsed by default. The positional `limit` argument could similarly remain supported until it has gone through a deprecation cycle. -- https://bugs.ruby-lang.org/