Renaming a deployed gem, best practices

[Jon Lunsford]

Has anybody had any experience renaming deployed gems? I'm wondering the best way to go about this. I maintain this gem that's a wrapper for the Yify movie API, but they have recently changed their name to "yts" so I'd like my gem (classes, architecture, etc.) to be named accordingly. Do I:

A) Update the existing gem even though the gem name is now inaccurate?

B) Deprecate this gem and release a brand new one?

[Johnneylee Jack Rollins]

Hello,

I would push a version of your gem where your constants are mapped to
the new constants and raise a warning at least once for a deprecation
warning.

Push this version out, and when you release a new version of the new
gem, you can either bump the old gem for a certain amount of time,
bumping the dependency constraint on your new gem, or you can simply
stop updating the dependency. I would caution against releasing a
'broken' version of the old gem to further encourage migration to the
new gem. I believe the warnings will be sufficient, especially if you
set a date or version that you'll stop updating the old gem to be
compatible with the new gem. This way new code gets into the new gem,
but the old gem is just a mapping of old constants to new ones.

So to answer your two-parter,

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

b) Eventually release the brand new gem because everyone will
appreciate it all the more when the gem name matches the top-level
constant(s) in their relative forms.

If I was confusing, I'd love a chance to clarify. I also screenhero
with anyone working on open source projects that want a pair, if
that'd be preferable.

~Johnneylee

> --
> You received this message because you are subscribed to the Google Groups
> "rubygems.org" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubygems-org...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Alex Chaffee]

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 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?

- A

--
Alex Chaffee - ale...@gmail.com
http://alexchaffee.com
http://codelikethis.com
http://twitter.com/alexch

[Johnneylee Jack Rollins]

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

>
> - A
>
> --
> Alex Chaffee - ale...@gmail.com
> http://alexchaffee.com
> http://codelikethis.com
> http://twitter.com/alexch
>