Handling updates delivery to OrbitKit users.

[ixahmedxi]

Hello everyone,

One of the biggest requests that I have received ever since OrbitKit became a thing is that once you start using it, you're kinda stuck with that version until you manually put in the time to look at the differences, new updates and match that.

Ultimately, there should be a way to update your project that uses OrbitKit so that it matches the main of this repository.

Ideas that came to me:

• Make some sort of a Github application that automatically makes pull requests into your own repo whenever a release is done on OrbitKit?
• Maybe a CLI that you gotta call whenever you want to update your codebase to the latest of orbitkit?

But with any solution, how would we be able to handle conflicts between your version of orbitkit and ours?

Anyways, input is welcome to try and refine the path with this.

[adamburmister]

First up, thanks for the project. I'm loving it. I wanted to learn about Turbo and this has really helped me kick things off.

A big +1 to updates being the biggest current pain point.

After doing project renaming and some customisation, the update process becomes very manual for me. I'm basically watching the project and stepping through each merged commit set to pick out the pieces I want (sometimes a cherry pick works, otherwise I am literally scrolling through and copying pasting some relevant bits).

I'm about to replace the app/web with a Rails one, so you can see how things are going to get funky the further I stray from the main-branch state.

My quick thought is that Orbit kit shouldn't ship with apps already in place, but rather generators for those apps. Then you can keep the generators up to date and not worry about conflicts with a fork's apps, and hopefully those generators could present a diff of the core files (turbo, configs, etc) for the forker to apply.