Backports v4

[marcandre]

Backports v4 roadmap:

• Drop backports for Ruby < 2.1
• Make require 'backports' a noop (or an error?)
• Remove stdlib support
• Remove rails

ETA: Xmas '20

[marcandre]

• Use prepend or keep using alias_method_chain?

[marcandre]

I wouldn't mind having a nicer API too. E.g.:

Backports.update :to_h, :transform_values, up_to: 2.7

That would still be susceptible to forward incompatiblities if the up_to argument is optional.

/cc @zverok

[zverok]

Thinking about it a bit, I'd say this:

1. There is a completely different level of "threat" for methods that are new (like Enumerable#tally) and methods whose behavior is redefined (Enumerable#to_h)
2. I believe that drawbacks of the methods of the first kind in most cases could be neglected (e.g. delegated to backports user's responsibility), while drawbacks of the seconds are various (performance penalty, possible incompatibilities)
3. A lot of times, nobody thinks "oh, I want a method(s) from that Ruby version", rather "oh, I used to that method/I read about that method in some tutorial, can I have it please?"

So, I think along this lines:

1. Somehow define what methods are new, and what are redefinitions
2. Then, provide this API:

Backports.require! # requires all new methods, no redefinitions
Backports.require!(redefinitions: true) # all new and redefinitions

Backports.require!(redefinitions: true, except: %w[Enumerable#to_h]) # but not that one
Backports.require!(only: %w[Enumerator.produce]) # I am picky today!

Backports.require!(upto: 2.6) # don't take nothing from 2.7

(For some cases, it will also require some reconciliation of "what means what", for example, if somebody asks for Enumerable#to_h, does that mean they want Array#to_h too? Most probably... But does that mean they also might want to opt-out of "just Array#to_h"?)