Contact Github to turn this fork into its own project.

[BobbyMcWho]

Currently, you cannot do things like search this repo due to the fact that it is a fork. Since this is the maintained version of this project, please contact Github to make this its own project. https://help.github.com/articles/why-are-my-contributions-not-showing-up-on-my-profile/#commit-was-made-in-a-fork

[mvz]

@BobbyMcWho that sounds like a good idea. Are there any downsides to breaking the connection with @jnunemaker's repo?

[BobbyMcWho]

None that I'm aware of, though I have not done this before.

[jnunemaker]

I can add people to the repo and to the gem if that would be helpful.

[BobbyMcWho]

@jnunemaker up to mvz, I think the project has been forked and maintained long enough, and the fact that this version of the gem uses another name on rubygems, means that we should leave this as its own repo, just split off so that it's no longer considered a fork for the reasons specified above.

[mvz]

I see two options for the future:

One is where there is one core implementation of HappyMapper, and developers can choose to use either Nokogiri, libxml-ruby, or maybe something else to do the XML parsing. To achieve this, there could be gems happymapper-core, happymapper-libxml-ruby, and happymapper-nokogiri. For backward compatibility, happymapper would depend on happymapper-core and happymapper-libxml-ruby, and nokogiri-happymapper would depend on happymapper-core and happymapper-nokogiri.

The other is where we basically continue as is, with happymapper being basically frozen and unmaintained, and nokogiri-happymapper going its own way.

I'm wondering if breaking the connection would definitively break off the path to the first future. Probably not ...