Closed barriehadfield closed 7 years ago
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
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.
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
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
Please comment on the proposal above. If we can get agreement today then this work can perhaps be done over the weekend.
Rename hyper- reactrb. Now and be done
I guess my second choice is hyper-act
Further discussion with @catmando and he is OK with Reactrb being renamed "Hyper-react" to preserve the linkage with React.
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.
Hyper-mesh - any takers, going, going, gone...
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
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.
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).
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"!
@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:
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)
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?
finally there are bunch of backward compatible patches to hyperact (boy do I like that name better ) that hypermesh needs. Currently hypermesh monkey patches hyperact, but it would be good to just incorporate the patches into the initial release right? They are all documented as issues #176 #177 and #178
BTW and can we drop the dashes if it makes sense or do we need to be consistent?
alternatively:
Would it be better to just make branch on each repo called "hyperloop-rename" that just has the updated gemspec pointing to the new name, and referencing any other hyper gems by their new name.
Then we just rename the repos
and finally merge the branches
seem good?
@zetachang if that seems good can you update reactrb and add those patches I mentioned?
I think I will go for making a new branch as you said first.
Another question is: do we move all our modules to a unified namespace, like Hyper
or Hyperloop
?
The initial attempt on hyper-react is in this pr and the gemspec is updated, so point to hyper-react
branch will work.
So the hyper-react gem renaming is done and released as v0.10.0
@zetachang @catmando I have brought the website up-to-date with the current state of the gem renaming. I think I have completed everything for HyperReact, HyperMesh, HyperTrace and have left reactrb-router and reactrb-rails as they are until the gems change. I have not done the tutorials yet as they require the source code being updated as well. Please let me know if you see anything I have missed. Sorry for being slow!
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: