Auto-Update with Scriptable Symbols

Dear Unity Team,

Sometimes it’s necessary to not only upgrade but also downgrade Unity versions (e.g., because the newer version turns out to not be supported by some assets). Therefore, it would be very helpful if your auto-updater of API changes worked in both directions.

Or even better: if it added scriptable symbols automatically and also recognized them later (currently, the auto API updater is ignoring them and tries to update the “not used version” scriptable symbol part).

Since you often rename functions or parameters, etc., it’s really a mess to change Unity versions. You could also allow scriptable symbols for smaller versions, e.g., with your newest changes with “linearVelocity” instead of “velocity” or “angularDamping” instead of “drag” from Unity 2023.3.0a17 that affect a lot of assets from the store like FinalIK or PuppetMaster - and are not solvable by your standard scriptable symbols, nor by your API auto-updater.

Example (best if you would do this automatically):

#if UNITY_2023_3_0A17_OR_NEWER
Vector3 velocity = r.linearVelocity;
Predict(r, steps, out position, out rotation, Physics.gravity, r.linearDamping, r.angularDamping);
#else
Vector3 velocity = r.velocity;
Predict(r, steps, out position, out rotation, Physics.gravity, r.drag, r.angularDrag);
#endif

Thank you for your attention to this matter.

Best regards,
Michael

Downgrading isn’t going to ever happen because old information gets lost. If Unity4 had settings related to Blackberry, those settings are going to be GONE, just as a single simple example.

Not only that but it becomes an ever-increasing web of possible back-and-forth that provides almost ZERO value to anyone except developers who are undisciplined with source control and testing. This isn’t a cadre of developer that should be catered-to support-wise when there is so much more valuable work to do moving the engine forward, fixing bugs, etc.

Upgrading is NOT a casual “Aw gee, what the heck, I’ll give it a try!” process.

ALWAYS have an economic reason you are upgrading.

ALWAYS use source control and proper testing before you upgrade.

Here’s some more thoughts:

ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)

Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also “play nice” with the new version of Unity. Since you didn’t write the third party library, it is up to you to vet it against the new version to make sure it still works.

If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

Do not upgrade “just for fun” or you may become very unhappy.

ISSUES RELATED TO GOING BACK OR UNDOING BREAKING CHANGES TO YOUR WORK

Keep in mind that Unity does NOT back your files up. That’s on YOU.

Use either version control (see below) or else make your own backups.

PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL

I’m sorry you’ve had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://discussions.unity.com/t/736093/3

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

https://discussions.unity.com/t/807568/3

Using fine-grained source control as you work to refine your engineering:

https://discussions.unity.com/t/826718/2

Share/Sharing source code between projects:

https://discussions.unity.com/t/719810/2

Setting up an appropriate .gitignore file for Unity3D:

https://discussions.unity.com/t/834885/5

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)

Setting git up with Unity (includes above .gitignore concepts):

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It’s simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

Source control does require learning, but there are TONS of tutorials and courses and online reference.

You should strive to use source control as confidently as you use your file/folder system.

“Use source control or you will be really sad sooner or later.” - StarManta on the Unity3D forum boards

Kurt already said it but it needs to be stressed: you don’t figure that out in your current project after having done some work. You test the new project version as well as you can in a COPY (branch) before committing to it.

If that asset doesn’t support the Unity version, it’s something you ought to catch. Especially if its fundamental functionality that doesn’t work, let alone a compile error that pops up right away.

Btw, Unity mentions this in the “editor version doesn’t match project version” dialog that opening a project in an older editor version is unsupported.

Thanks for your fast answers @CodeSmile @Kurt-Dekker .

Of course we working with different copies and GIT, however, when you have a big project (around 1 TB) and you have to use newer Unity versions (because the editor became faster and e.g. WebGL builds took AGES (4h+) before some newer updates) but at the same time those newer versions are having issues with plugins or assets - then you might appreciate a solution for testing version related errors without spending hours to copy around projects or git revert all the time.

It’s clear that working on a tiny casual game or so won’t have such issues and that it’s never funny to change versions in general.

Unitys API auto-updater could easily keep the original version in a scriptable symbol which is set automatically by Unity - then we would NOT lose information like described by your Blackberry example. Also in my eyes, API auto-updater should not update those lines that are within an inactive scripting symbol (or it should ask about this too, to give me a choice), otherwise it’s much harder to have different Unity version support.

I ask myself: If supporting more than one version of Unity is a must-have for e.g. most assets from asset store and there exists a support for Unity version related scripting symbols, why would I want to have API auto-updater “fixing” my correct code? Of course I can decline to update automatically, but this is then declined for ALL updates and not just those inside the scripting symbols.

Honestly, I don’t have the time and don’t want to discuss general topics like “is it good practise to go back to older versions, if the new version fails at some point without just reverting back everything”, because this very much depends on the practical situation of each company and different experiences made. In theory - or in tiny projects - it’s not likely that you switch to a newer version and only find bugs or problems preventing you to use this newer version (and having to switch back) after weeks or even months - with dozens of developers updating the newer version code. But the bigger your project becomes, the more people you have working on it and the more unexpected the (often Unity related) errors are (not easily showing up with error messages), the more likely you will get a situation where you have to deal with e.g. 2 parallel project versions with 2 parallel Unity versions - covering those differences in your code with scriptable symbols.

My post was just a suggestion for Unity, not a start of general discussion about good coding practises. I agree with you both, however, as I wrote in the beginning: “SOMETIMES it’s necessary to also downgrade” - and in this case, I really wonder, why auto-updates can’t just automatically set the right scripting symbols, this doesn’t sound too hard to me and might help keeping a better overview about code changes without searching GIT - beside having scripts working for different versions without troubles.