Remove support for alternate JSON backends

[iainbeeston]

I want to resurrect #206 , which removed support for alternative JSON backends. I believe that rather than putting this off to a version 3.0 release which will probably never come, we should merge this in now, in a way that is as backwards compatible as possible. I believe it could be done in a minor release, so long as we keep the external methods related to setting the json backend.

The one catch here is that Ruby 1.8 doesn't come with the json gem, and it would need installing by default... but in reality json-schema hasn't worked with ruby 1.8 for some time.

[RST-J]

I personally do not have a problem with that, but I'm not sure whether is consistent to remove alternative JSON backend support in a minor version. But if I see it correctly, other backends can still be used, only the way how to achieve this changes (enabling compatibility mode instead of setting a multi-json backend). And I see another argument for doing this: Currently, two installations of a project can behave differently depending solely on the fact that in one environment the multi-json gem is installed and in the other not. So I'd say, we should do it. :+1: @pd or @hoxworth any comments on this?

[iainbeeston]

I agree, it's not clear whether this is a breaking change (and therefore whether it would need a major release).

My argument is that this can be released in a minor version, because so long as you're using ruby 1.9+ (and json-schema has major bugs on ruby 1.8) you do not need to update your code to use this branch. Even if you were previously using multijson or oj or yajl or whatever, json-schema would silently fall back to using the standard json gem. You might get better performance by making yajl or oj use compatibility mode, but nothing will break. What's more, if you are explicitly setting the json backend, we show a deprecation warning, which I hope will make it obvious to anyone who does not read the changelog when upgrading.

[iainbeeston]

It's been 3 months since this was raised... Any thoughts?

[RST-J]

To me it is fine to merge this. If it - possibly - only breaks things that have been broken before there is no point in deferring this.

[RST-J]

So, do we merge this?

[iainbeeston]

@RST-J I think we should merge this (after I rebase, of course)

[leoarnold]

@RST-J @iainbeeston Are you still on this? MultiJSON is causing an intricate headache: https://github.com/ohler55/oj/issues/441#issuecomment-355593741