I have a very simple asset I originally made under Unity 2018.3. There are a couple of bugs with it, and some 2019.X-specific warnings, so I’m about to go fix those and release a new version. But now I’m wondering what’s an efficient way to develop against multiple Unity versions.
The easiest thing would be to open my asset’s project in 2018.3, make the code changes, then open the same project in 2019.1, and do any additional 2019.1-specific work. However, if I actually upgrade the project, I can’t go back to opening it in 2018.3 anymore.
The other approach is to develop it in the latest version of Unity, then export it to a package, then import it into a 2018.3 project, and see if it works. But this seems like a big hassle.
I know about precompile directives to conditionally include code depending on the Unity version, but it’s more about the difficulty of writing code for another version of Unity without being in that Editor at the time.
So I was wondering what you all did to address this? Is there a better approach than export → import → see if it works?
Don’t back-import into older Unity versions. It might work with code, but it can introduce all kinds of problems with serialized assets, some of which you might not catch but customers will be sure to.
Develop in the oldest version of Unity that you plan to support (e.g., 2018.3 in your case).
Set up additional projects in newer versions of Unity that have API changes that affect your asset.
Use the Unity version compiler defines you mentioned to handle API differences among different Unity versions. Export your asset from your dev project and import them into the additional projects. Ideally you’ll use a tool to do this automatically as well as kick off automated tests in each project. I use uTomate, which is unfortunately no longer available to buy on the Asset Store, but similar tools are on the horizon or you could write your own. You may find it easier to initially make and test edits in the newer project, then apply them to your dev project and do the export->import process to test it.
So the short answer is yes, export → import → see if it works, but automate the process.
Also, this page is invaluable: Unity API Versioner. It lets you look up when API changes were made by version.
Last, this probably won’t apply in your case but may apply to other asset devs: If you’re making a Complete Project asset that includes ProjectSettings, you may need to maintain release projects in multiple versions of Unity to handle version-specific project settings, such as .NET3.5 Equivalent in your 2017 project vs. .NET4.x Equivalent in your 2018+ project. You’ll still want to follow the same export-import dev process, just with this extra wrinkle.