Gem renaming

[barriehadfield]

At the moment we have many combination of Gem names and it would be very good to agree a consistent approach then update the website, gem documentation and the gems themselves.

@catmando has suggested renaming all the gems Hyper "something" so we would have:

• Hyperloop as the umbrella name
• Hyper Act (or could also be Hyper Reactrb for now until the DSL is split)
• Hyper Record (combination of Reactive Record and Synchromesh)
• Hyper Router
• Hyperloop Express

[catmando]

do be a bit more precise:

Official Name: Ruby Hyperloop

In day to day discussion shortened to "hyperloop"

gem names (proposed) (I am good with whatever in terms of when to use/not use dashes... I really like dashes better than _ in gem names is my only preference.)

hyperloop This gem will include basically all the other gems, plus latest rails components, so that you can just install hyperloop and go. Similar to the way volt worked which I think was a big attraction.

The react dsl: hyper-dsl or hyper-ruby or hyper-react or hyper-act (I think we just go ahead pick the one we like and make the name change now, even though there are just a few extras in there, that can be moved to hyper-store later) My favorite as of 9:16 AM is hyper-ruby. I am feeling that the link to react is so obvious, that what we need to emphasize is what is new which is ruby.

hyper-store: (Grab this while its available) will be where the the reactrb advanced state management stuff gets pulled out to, with perhaps some repartioning of the parts of reactive-record that are independent of active-record.

hyper-rails: Rails support (generators, prerendering, etc)

hyper-record: (or perhaps hyper-mesh) I agree that with the rename we just integrate synchromesh and reactive-record. Initially it will require rails, but over time we can make it more flexible in terms of the underlying framework. Not sure about the name. As fun as reactive-record was, I felt it never got traction, I am thinking that hyper-mesh will be more interesting. Tag line active-record models on the web If we agree on hyper-mesh, then we can keep hyper-record as the traditional client driven version at least for now.

hyper-router or perhaps hyper-route which is nicer to say I think, and sounds cooler.

hyper-spec rspec support

hyperloop-express

[barriehadfield]

Thank you @catmando. I agree with everything above except hyper-ruby as the full name would be "Ruby Hyper-ruby" which is just not right. Also, I think the tie to React is important, it might be obvious to you as you live and breath it. I really think the tie to React needs to be maintained. I would vote for "Hyper-react" instead.

[barriehadfield]

From @fkchang:

I think there is value in keeping react in gems that directly apply, we want the SEO/name value
wrt to splitting out dsl and dom, react and react-dom is something we should probably emulate, possibly reactrb-dsl, reactrb-dom
maybe no hyper on the gem name to keep the react brand recognition, but it should be ok to have things in the umbrella that aren't hyper, no?
but if not hyper-reactrb-dsl and hyper-reactrb-dom are ok, but maybe come off a little to extreme (as in X games), to me, but I'm flexible as long as we can ensure the react branding (which is significant) tie in

[barriehadfield]

Proposal taking all the above into consideration:

Repro and website

Official Name: Ruby Hyperloop
Official Github repo: https://github.com/ruby-hyperloop.io
Official Website: http://ruby-hyperloop.io

In day to day discussion shortened to Hyperloop or Ruby Hyperloop when its necussary to be more specific (like in any outside context)

Strap line: The Missing Ruby Front End Library

Old reactrb.org redirects to http://ruby-hyperloop.io/reactrb/
Old github.com/reactrb redirects (via message) to https://github.com/ruby-hyperloop.io

Gems

• Hyperloop This gem will include basically all the other gems, plus latest rails components, so that you can just install hyperloop and go. Similar to the way volt worked which I think was a big attraction.
• Hyperloop Express All gems necussary for client side compilation with no server side installation.
• Hyper-reactrb Reactrb gem as it is today. Simply called Reactrb with no rename other than adding Hyper to the documentation and website. When this gem is split into its component parts they will each become Hyper-... (Eg: Hyper-react, Hyper-DSL, Hyper-act, Hyper-ruby, Hyper-reactrb or other). We delay this decision until the code is ready to split into multiple gems.
• Hyper-rails Rails support (generators, prerendering, etc)
• Hyper-router renamed Reactrb Router
• Hyper-spec rspec support
• Hyper-mesh and/or Hyper-record Reactive Record and Synchromesh gems merged into a single gem. If this merge is imminent then lets do it now and push ahead with one of the names. If it is not then lets use both names for now the select which name to go forward with later. (I think they are both good names for the combined)
• Hyper-store (Grab this while its available) will be where the the reactrb advanced state management stuff gets pulled out to, with perhaps some reapportioning of the parts of reactive-record that are independent of active-record.

Please comment on the proposal above. If we can get agreement today then this work can perhaps be done over the weekend.

[catmando]

Rename hyper- reactrb. Now and be done

[catmando]

I guess my second choice is hyper-act

[barriehadfield]

Further discussion with @catmando and he is OK with Reactrb being renamed "Hyper-react" to preserve the linkage with React.

[catmando]

FYI... lets go ahead and call synchromesh hyper-mesh or hyper-record now... synchromesh is a superset of reactive-record anyway. The only longer term issue I would like to solve before decommissioning reactive-record completely is making sure that synchromesh behaves nicely even if you don't set up a push transport. I.e. if for some reason you just want to do traditional CRUD activities from browser to server.

I am really torn between hyper-mesh or hyper-record, so I will let better marketing minds decide.

[barriehadfield]

Hyper-mesh - any takers, going, going, gone...

[fkchang]

does hyper-react give any nod to ruby, will it be obvious to people not in the project. I kind of like @barriehadfield 's ideas keep it reactrb until we split. I believe the 1st split will be dsl and dom, just like react.js and react-dom.js.

I still think our tie in to react needs to be emphasized for people outside the project, so reactrb-dsl and reactrb-dom when it happens (and hopefully soon after reactrb-native), woulc be good, there should be tons of links to the rest of the hyper-* stuff that we don't need to do that. But if we must go w/a hyper prefix, then hyper-reactrb pre split, and hyper-reactrb-dsl and hyper-reactrb-dom when we do split

[fkchang]

on hyper-mesh, what are our communication goals, if it's to be a superset of active record, hyper-record clearly indicates it's a more powerful active record. The mesh/syncromesh doesn't probably have any consistent semantic meaning.

[barriehadfield]

Thanks @fkchang for the feedback. To be honest, I think we are covered with Hyper-react as its proper name is "Ruby Hyper-react" and the whole drive behind the Hyperloop project is that its all Ruby (The Missing Ruby Front End Library).

[barriehadfield]

With Hyper-mesh vs. Hyper-record, they are both good names for different reasons. My vote is that mesh is stronger as the really valuable thing it brings is the magical client side sync of data. This is so different to ReactiveRecord and actually more comparable to Relay plus GraphQL plus Node.JS and some sort of client side listeners. Anchoring on ReactiveRecord does this technology no justice I think. Lets celebrate "what a mesh this all is"!

[catmando]

@barriehadfield @zetachang
Now that the repo is renamed, we have to rename the gem repos and the gems themselves.

What the procedure for doing this?

Do we just rename the repo, and then update the gemspec, keeping the version the same?

The problem is that the gems depend on each other so we have to do this in a coordinated fashion (right?)

here the dependencies as I understand them:

1. hyper-react (depends on nothing else in hyper-loop eco system)
2. hyper-trace: depends on nothing else
3. hyperloop express: depends on hyper-react, but only to build
4. hyper-mesh: depends on hyper-react and includes all functionality of reactive-record
5. hyper-route: depends on hyper-react is it going to be route or router?
6. hyper-rail(s): depends on nothing BUT mentions hyper-react, hyper-mesh and hyper-route(r) * is it going to be hyper-rail or hyper-rails? *

As far as reactive-record goes, as I have said my plan (unless someone is opposed) is to just leave it as in the repo with no further changes. The gem source will be merged with synchromesh to be the new hyper-mesh gem. The additional payload client side for hyper-mesh is pretty small (maybe 100 lines)

[catmando]

however to further confuse the above there are a couple of outstanding PRs for hyper-react, hyper-route. I think they should just be incorporated during the name switch yes?