I notice that for Entities 0.2.0 there is a UNITY_ENTITIES_0_2_0_OR_NEWER define. What is the life of these defines and where are they setup?
I’m wondering how long they will persist in Unity as new versions are released. For example, in UnityEngine you can still use something as old as say UNITY_5_3_OR_NEWER (even though this is out of support).
If they will persist over multiple years, being able to use them in tools for Entities and Unity.Physics would be very useful.
If you stay with same Unity, they will live indefinitely.
Simply, if you don’t wont to update entities and finding them braking your code, stay with last working Unity.
You shouldn’t have an issue.
Other than that, mind that Entities are still not for production and Unity Editor evolves as well.
Thx for the reply but I think you misunderstood my question.
What I’m really asking, like with the UNITY_5_3 define, is will the older ENTITY defines still be present in future versions like Entitles 1.0, 1.1, 2.0 etc (like they are in the Unity Engine with UNITY_n_n_OR_NEWER defines).
Also, where is the list of these for Unity.Entities and Unity.Physics declared?
When designing tools #defines are the only reliable way (that I know) of having a single code-based that will survive Editor and package upgrades. The API Updates doesn’t work in many scenarios so we need to write specific code for different package versions. A great example of this is say LWRP/URP/HDRP.
If you just had a single game or project, it would be simpler. However, with tools it is much more complex.
It’s a bit strange these are even needed to be setup to be honest. With assembly definition files you can declare your own defines based off the version of the entities package which would give you a lot more control.
Unity use them in their own coding samples. For example, in different versions of Entities, how the default world is referenced has changed. These make you code more portable across multiple package versions while keeping a single code-base. Also, when you need your code to work across several years (with all the different versions along the way) this is a requirement.
Yes, it would be nice if everyone would just use the latest version of everything but this is impractical. We have seen so many cases where a project can’t be (easily) updated because xyz feature in the newer version breaks something else.
I think you missed my point.
My point is you can create these version specific defines yourself in assembly definition files and have more flexibility over them while not relying on Unity to add them.
Ok, cool. Do you know if these are supported from U2017.4+. I know we looked at these a while ago and thought that the assembly definition files themselves had editor version dependencies.
I believe version defines in assembly definitions weren’t added till 2019.1