[Beginner] Upgrading philosophy between Unity versions

Hi,

I did some research, but since my question is a bit generic, I didn't really find an answer to it. I am a total Unity beginner (but a long-time developer). I decided to give Unity a go, and actually wanted to check a neat little game available here: https://cawotte.itch.io/small-islands (the Unity project is here: https://github.com/Cawotte/SmallWorld_WeeklyJam40).

This game was made with Unity 2017.3.0, and I try to open it with Unity 2018.3.3. Since there is only one year between the two Unity versions, I would expect things to go pretty smoothly. But the upgraded project is a mess, with many errors.

I tried to fix some of them, even if it's still very confusing to me as a Unity newbie:
- The AnimatedTile script was duplicated for some reason, so I removed one occurrence of this script.
- TextMeshPro seems now to be handled via the package manager, so I removed the code in my hierarchy too.

But after this, the game still doesn't work properly, and it seems some elements have to be reassigned manually to objects (maybe removing some scripts also removed their references to objects). But I can't see what should be reassigned, I just have messages telling me that some scripts can't be found, and I don't know how to determine what was the assignment in the first place.

So beyond this specific case, I am wondering what the Unity philosophy is regarding upgrades. I would have expected things to go smoothly from 2017 to 2018 versions of Unity. I suspect some issues are related to the relatively recent introduction of Tilemaps. However, does it mean that once you start a project with a version, it is better to stick to that version till the end? Does that also mean that you have to keep all versions of Unity installed on your machine, to be able to maintain your different projects? I would find it frustrating not to be able to improve a project with new Unity features, just because projects are a pain to upgrade.

Sorry if those are noob questions. Thank you for your opinion. Cheers!

 

My Philosophy for unity versions is, stick with it unless you have a good reason the change.
Sometimes consolidating projects on a stable version is a good idea like a LTS version.

 

For TextMeshPro, specifically, you'll have to follow the instructions here:
https://forum.unity.com/threads/mig...set-store-to-package-manager-releases.511748/

but you'll have to start over again for it to work.

I just went through all of this yesterday and it's not too difficult.

 

Early in a project you can be a little more liberal with your version upgrades, but expect to have to do some fixes even for seemingly minor version changes. Sometimes you get lucky with no issues, sometimes you get obvious console errors you need to address, sometimes you get subtle behavior changes to your game that may be difficult to even notice without a full QA pass.

Always use version control and/or backups, so you can easily revert your project after loading it into a newer version of Unity. The problems encountered may end up being bigger issues than anticipated, and not ones you want to tackle right now. Such as if the upgrade breaks a 3rd party asset, and the asset developer has yet to release an update to fix the issue. In that case it may be smarter to roll back and see if the asset dev puts out a fix, and possibly contact them with the issue, rather than trying to fix that asset yourself. Or even worse, throwing up your hands and putting your project on hold until the asset dev fixes the issue such as if there is some closed source component to the asset.

When your project is getting more developed you should have a final target build of Unity. That could be the version you're already on, or it could be a yet to be released LTS version. But you should have that plan. At some point you freeze your Unity version, not upgrading unless you discover some must have fix that impacts your project.

That's one reason having multiple versions of Unity installed is normal. You are very likely to have several projects in various stages of development. Some main project you're on, some other projects you've built prototypes for, some legacy projects already out the door but you still need to maintain, and all of them are likely to be on different Unity versions.

 

"Since there is only one year between the two Unity versions, I would expect things to go pretty smoothly." - yeah, that's not Unity's philosophy.

The yearly upgrades are the most major ones, going from 2017 to 2018 to 2019 will result in the biggest API changes. Each year Unity does 4 major feature updates, with the final update coming shortly after the next year's first version (so, Unity 2019.1 just got released, and 2018.4 LTS should arrive soon). The .4 versions are the "Long Term Support" releases, for companies that don't want to risk upgrading to a major new upgrade that could break big things. The LTS releases still get occasional bug fixes but no new features.

The big API changes and system rewrites happen (or at least, are made non-experimental) with the new year release. For example, according to Unity's blog, "Unity 2019.1 is packed with more than 283 new features and improvements."

Note, that doesn't necessarily mean that within a year there won't be breaking changes - for example, from Unity 2017.1 to Unity 2017.2 they changed the namespace "UnityEngine.VR" to "UnityEngine.XR". Although Unity does now have an automatic API updater that should fix many of those issues.

Oh, and yeah, Unity expects many developers to have multiple versions of Unity installed at once, that's why they made the Unity Hub, which is designed to associate different versions of Unity with different projects, so the correct version for a project is always loaded.

 

Thank you all for your explanations, it's much appreciated. And it is clearer now, cheers!