On Nov 10, 2011, at 1:31 AM, Rahul Kumar wrote:
> I have a gem that has been growing for a while (e.g. mygem). There's a
> lot of experimental stuff being added. So I'd like to have a mygem-core
> which has the basic stuff that should be stable and fairly frozen. Then
> i can quickly respond with a fix, rather than wait for the other changes
> to stabilize.

I prefer to:

1) Keep the original gem name
2) Make a plugin system and move the fast-moving parts into plugins.  The core gem should automatically load plugin gems.

> The other stuff can go into mygem-extra or mygem-utils and
> mygem-experimental. Some of it may move from "experimental" to "util" or
> "extra" as the API stabilizes.

Give each experiment a reasonable name and release them as separate gems, especially if you're not interested in maintaining or exploring them forever.  This allows you to hand them off to more-interested maintainers or abandon them without breaking API.

> I am not clear what the best way is. Do i keep the original gem name and
> make it implicitly the "core" removing all other stuff from it. Or
> should i create new gems for these 3 or 4, meaning that the original gem
> (name) will no longer exist.
> 
> Should i keep it in one git repo within the same directory structure
> (meaning multiple gemspec files). Or divide/clone it into separate
> github repos. However, I am hoping that even across these gems the root
> directory will still be my gem.

Use separate repositories for separate gems.  You can create an organization for your repositories on github.

> Will dividing the gem lead to other problems ?


Splitting up a gem won't lead to other problems by itself.

To save yourself a possible hassle, avoid having = dependencies between the pieces.  An = dependency forces you to release at least two gems at once if you want both pieces to be using the latest code.  Instead use ~> to specify a version range that is acceptable.