How to setup a project that uses multiple Unity versions?

[JEP]

We're looking at moving to Plastic SCM (from the laughable Unity Collab/Teams/Collaborate/Even-they-don't-know-what-they-want-to-call-it). But we have a bit of a tricky project to figure out how to represent.

It's a project that we started out building in Unity 2019.3.15f. The main coder picked that one because it contained some really important fixes/improvements in the hardware we were running our VR app on. However, we wanted it to support a different piece of hardware, and that one's SDK only supported up to 2019.3.6. So he created a separate Unity project for it with changes specific to that hardware.

Ideally, we want a better way of representing that 95% or more of the code is identical between those two projects. They are the same application, just supporting two different pieces of hardware. But from what I can tell, Unity is pretty fussy about you flipping back and forth between Unity versions within one project.

Any tips on the best way(s) to set this up in Plastic? I've been reading all about submodules and Xlinks, but I'm not sure either really fit what we're doing. In general, the developer(s) will have two folder on his disk, one for the main project and one for the forked version that supports the new hardware. Generally, branches seem more geared towards merging stuff back in. And we'd want to have changes that are in the main branch get transferred over to the forked version on an ongoing basis.

Not sure how to approach this, both from a Plastic and Unity standpoint. I'm sure Unity will be happy with just having two folders and pretending they are completely different projects. But how Plastic best works into that I'm not sure.

[calbzam]

Hi,

Quote

In general, the developer(s) will have two folder on his disk, one for the main project and one for the forked version that supports the new hardware. Generally, branches seem more geared towards merging stuff back in. And we'd want to have changes that are in the main branch get transferred over to the forked version on an ongoing basis.

- According to your feedback, using branches may fit with your needs. You can create independent dev branches for both versions/projects. From each dev branch, you can create different task branches that can be merged to their parent dev branch but also to the other project. If both versions come from the orginal same version and you have some common tasks that you need to integrate in both, it makes senses using branches on the same repositpory.

- If the projects are independent, it's better to use independent repos to manage each project. A typical scenario for using Xlinks is when you have a library that needs to be shared between both projects. In the following blog post we explain a more advanced scenario, while different versions of the library are shared between the different parent projects.

http://blog.plasticscm.com/2014/08/how-to-share-engine-repository-between.html

Regards,

Carlos.

 

[JEP]

Thanks. I did not realize you could make a third branch (after /main and /secondaryhardware) and then merge it into both branches.