I would like to get your input on something. Basically, my client has a live version of their platform that consists of 3 apps (Frontend, Backend and API) that have separate Github repos. There is an urgent requirement to build a V2 of the service that will be using completely different data sources to process.
Because of urgency and to reduce the risk they proposed the following:
- Keep V1 as is
- Clone V1 into V2 and change the data sources and deploy it on separate AWS instances.
They want to Fork the repos to avoid risk, but eventually, want to merge V2 and V1 (so they want to remain eventually with just 3 repos as it is now, but every app would be able to accommodate both old/new data).
If we fork these we end up maintaining 6 repos and I can see a huge pain when trying to merge them back together eventually. Plus the code collaboration would become more complicated.
I am inclined to instead of forking create a v2 branch on each of repos.
The advantages that I see:
- easier to maintain
- increased visibility
- easier to merge in the end
- probably one big PR in the end on each of the apps
- merging v2 branch with the master on each of the repos has to happen simultaneously on all 3 apps (although feature flags could be used)
Note: All 3 apps are pretty complicated with big codebases and they work tightly together.
What are your thoughts?