Unity requires a data structure for the Unity version

The latest Unity LTS crashes on Undo for months now and Unity didn't deliver a fix so far. That's unacceptable as this is a highly critical bug.

In order to disable Undo code for a range of Minor versions the checking for the Unity version with Application.unityVersion isn't helping because that's just some random string that doesn't have a defined format one can rely on.

In order to be able to check for the proper major/minor/whatever version in the future I suggest do provide a proper data structure rather than a meaningless string.

Maybe I'm missing something here, but calling it "meaningless" or "just some random string" is simply wrong. The format is pretty clear and logical.

Let's take 2022.1.0f1 for example:
2022 - the year, higher = newer
1 - sub-release of that year, 2017-2019 the LTS version was 4, since 2020 LTS version is 3, higher = newer
0 - patch release of that version, higher = newer
f - full release, can also be a for alpha or b for beta, f > b, b > a (in 2017 we also had p > f iirc)
1 - minor version of that release, used for very small fixes on f versions (quite rare) or breaking changes for new alpha/beta versions, higher = newer

That last part might be a bit confusing at first, but as far as I can remember it always followed the same pattern. f is higher than b, b is higher than a. While in f versions the last number rarely changes and is only used for minor fixes, it changes almost weekly in alpha/beta versions and often has breaking changes.

xxxx.x.0f1 is higher than xxxx.x.0b13
xxxx.x.0b13 is higher than xxxx.x.0a20

Following this, xxxx.x.1a3 is in theory higher than xxxx.x.0f1, but I don't think there ever was any alpha/beta version higher than xxxx.x.0, so this doesn't really matter.

Before Unity 2017 (Unity 4/5) the versioning was different and also had a p letter, standing for patch releases. I don't remember the exact rules there, but I think the p letter meant it was higher than f. (The p letter was also used in 2017 versions)

So yeah, as long as Application.unityVersion reliably returns the current version, you can easily create your own data structure using it, except if it's broken or if I'm not understanding your request correctly.

2 Likes

[quote=“Armynator”, post:2, topic: 898076]
Maybe I’m missing something here, but calling it “meaningless” or “just some random string” is simply wrong. The format is pretty clear and logical.

Let’s take 2022.1.0f1 for example:
2022 - the year, higher = newer
1 - sub-release of that year, 2017-2019 the LTS version was 4, since 2020 LTS version is 3, higher = newer
0 - patch release of that version, higher = newer
f - full release, can also be a for alpha or b for beta, f > b, b > a (in 2017 we also had p > f iirc)
1 - minor version of that release, used for very small fixes on f versions (quite rare) or breaking changes for new alpha/beta versions, higher = newer

That last part might be a bit confusing at first, but as far as I can remember it always followed the same pattern. f is higher than b, b is higher than a. While in f versions the last number rarely changes and is only used for minor fixes, it changes almost weekly in alpha/beta versions and often has breaking changes.

xxxx.x.0f1 is higher than xxxx.x.0b13
xxxx.x.0b13 is higher than xxxx.x.0a20

Following this, xxxx.x.1a3 is in theory higher than xxxx.x.0f1, but I don’t think there ever was any alpha/beta version higher than xxxx.x.0, so this doesn’t really matter.

Before Unity 2017 (Unity 4/5) the versioning was different and also had a p letter, standing for patch releases. I don’t remember the exact rules there, but I think the p letter meant it was higher than f. (The p letter was also used in 2017 versions)

So yeah, as long as Application.unityVersion reliably returns the current version, you can easily create your own data structure using it, except if it’s broken or if I’m not understanding your request correctly.
[/quote]

That’s an obvious yet undefined pattern nobody can rely on and can change at any time. It’s not an API. And why should everyone have to write their own parser for that? Unity may as well add a parser as editor utility. On that one can rely on.

@Armynator side note, there's also the version numbers used in China, which as far as I know amounts to "c1" tacked on to the end.

@Rowlan
Recognizing that doing the following for a wide spread of editor patch versions is excessive, you can still use C# #if directives, for example UNITY_2019_4_14. Chain together editor versions that are safe or broken that way. That's for the granularity of patch. UNITY_X_Y_OR_NEWER is a thing as well. This is generally the best way to design against different editor versions. Failing that, there's always the option of a regex in your code and never looking back because it's highly unlikely anything will change, and getting the version pieces specifically seems like such a niche use case that it shouldn't warrant needing to put something in the class library for it.

[quote=“Spy-Master”, post:4, topic: 898076]
@Armynator side note, there’s also the version numbers used in China, which as far as I know amounts to “c1” tacked on to the end.

@Rowlan
Recognizing that doing the following for a wide spread of editor patch versions is excessive, you can still use C# #if directives, for example UNITY_2019_4_14. Chain together editor versions that are safe or broken that way. That’s for the granularity of patch. UNITY_X_Y_OR_NEWER is a thing as well. This is generally the best way to design against different editor versions. Failing that, there’s always the option of a regex in your code and never looking back because it’s highly unlikely anything will change, and getting the version pieces specifically seems like such a niche use case that it shouldn’t warrant needing to put something in the class library for it.
[/quote]

I thought of that, but all I see is this:

8538302--1140536--upload_2022-10-25_14-26-44.png

No minor version.

My logs (2022.2.0b12) indicate otherwise.
8538326--1140542--upload_2022-10-25_5-45-33.png

[quote=“Spy-Master”, post:6, topic: 898076]
My logs (2022.2.0b12) indicate otherwise.

[/quote]

There’s no way you can limit 2021.3.9 to 2021.3.11 with these, ie those are the versions where eg Undo needs to be disabled in code because it hard-crashes Unity when you press ctrl+z. It’s supposed to be fixed in 2021.3.12

[quote=“Rowlan”, post:7, topic: 898076]
There’s no way you can limit 2021.3.9 to 2021.3.11 with these, ie those are the versions where eg Undo needs to be disabled in code because it hard-crashes Unity when you press ctrl+z. It’s supposed to be fixed in 2021.3.12
[/quote]

#if !(UNITY_2021_3_9 || UNITY_2021_3_10 || UNITY_2021_3_11)
// Why not?
#endif

[quote=“Rowlan”, post:1, topic: 898076]
The latest Unity LTS crashes on Undo for months now and Unity didn’t deliver a fix so far. That’s unacceptable as this is a highly critical bug.

In order to disable Undo code for a range of Minor versions the checking for the Unity version with Application.unityVersion isn’t helping because that’s just some random string that doesn’t have a defined format one can rely on.

In order to be able to check for the proper major/minor/whatever version in the future I suggest do provide a proper data structure rather than a meaningless string.
[/quote]
Sidenote, do you know if there is a bugreport about this undo crash? Id give all my votes in an issuetracker.

[quote=“TJHeuvel-net”, post:9, topic: 898076]
Sidenote, do you know if there is a bugreport about this undo crash? Id give all my votes in an issuetracker.
[/quote]

This one:

https://issuetracker.unity3d.com/issues/2021-dot-3-editor-cashes-on-gettransformaccess-when-undoing-duplication-of-a-canvasrenderer-gameobject

1 Like

Found a way that is acceptable for me. The versioning in the assembly definitions follows a strict defined pattern.

Assembly definition file:

8547923--1142648--upload_2022-10-29_9-3-6.png

Code:

#if UNDO_DISABLED
...
#endif
2 Likes