In the 'seperate forks' case, would only the v2 fork be the one that's retained afterwards?
If so, then the branch approach's equivalent would be to afterwards not merge V2 into v1/master/main but just reassign V2 to be the master/main branch.
If not, then you'd need to merge the fork back into the v1 repos, which would be the same or (likely) more effort than in the case of branches, and in the meantime you lose a lot of convenience with regard to easy branch comparisons and patching v1 fixes to v2. And you'd similarly also need to do that at the same time for 3/6 repos, so nothing would be gained there.
In the 'seperate forks' case, would only the v2 fork be the one that's retained afterwards?
If so, then the branch approach's equivalent would be to afterwards not merge V2 into v1/master/main but just reassign V2 to be the master/main branch.
If not, then you'd need to merge the fork back into the v1 repos, which would be the same or (likely) more effort than in the case of branches, and in the meantime you lose a lot of convenience with regard to easy branch comparisons and patching v1 fixes to v2. And you'd similarly also need to do that at the same time for 3/6 repos, so nothing would be gained there.
Hi, Alain both V1 and V2 would be retained but they would want to eventually merge V2 into V1 and keep both versions under one codebase.