On Tue, Sep 15, 2015 at 7:16 AM, Alex Chaffee <
al...@stinky.com> wrote:
> On Mon, Sep 14, 2015 at 9:26 PM, Johnneylee Jack Rollins
> <
johnneyle...@gmail.com> wrote:
>> a) Update the gem insofar as making the old gem's constants point to
>> the new gem's constants and push that as a version with warnings
>
> Are you suggesting that the old gem (yify) contains all the same
> source code as the new gem (yts), plus a constant mapping layer? Or
> that the old gem get hollowed out -- all files gone except for the new
> constant mappings -- and add a dependency to the new gem? Those both
> sound pretty slick.
I would suggest removing the contents of the files in the gem's
require path(s) and replacing the code in those files with two things.
The first is the require line(s) for the new gem's require path and
then the code that map the constants from the old code to the new
code. That way you provide backwards compatibility for both constant
mappings and require paths. You keep the files themselves because
someone's code may be requiring that particular file in the load path,
but you place the require for the new gem and the mapping in that file
for each file in the require paths. It helps to consider the require
paths as part of your gem's public API because code will most likely
break if they change or disappear.
The dependency isn't on the new gem, the old gem depends on the new
gem. That way you can use the new gem and chug along happily, and if
you're using the old gem, it will pull in the new gem and your
constant mappings will work. The new gem shouldn't need to depend on
the old one. The old one just preserves require paths and constant
mapping.
An idea could be that your warning(s) suggest moving to the new gem,
and the new gem could provide a fairly simple `Yify = YTS` or whatever
the new constant is. You could put that in the new gem at some path,
either in the require path or you could use require_relative and place
the file outside of the require path. Call it something like
backwards_compatibility.rb and then, for some time until a date or
version, require that file in every file in the require path for the
new gem. It just really depends on how you write your gem though.
Maybe all require paths require the top level require path for the gem
(ex: require 'yts'), so the mapping could go there in one place
without much fuss. If your gem doesn't do that, you might want to try
the separate file like I suggested.
>> I also screenhero with anyone working on open source projects that want a pair
>
> What a great idea. How do you promote this? How do you schedule it?
Usually just by telling people. I'd definitely like any suggestions
for useful tooling that makes it easy to not just schedule, but
promote that I love to pair on open source projects with people, even
when they aren't using tools that are my forte. Also, do you want to
pair on something?
~Johnneylee