I’ve recently realised that I have an old Burst package version (1.6.6), but when trying to update it from the package manager I’m still getting a version that’s a three months old and several version behind the current verified version (1.7.4 as of now).
I’ve manually updated to 1.7.4 and even now I’m getting a message recommending the 1.6.6.
Some context; I’m currently at Unity 2021.3.5f1 LTS, I’ve tested it and using Unity 2022.2 I get the 1.7.4 as recommended.
Is there any reason behind this incongruence? I know latest != best and it’s a good idea to slowly roll changes, but I believe it’s been quite some time and unless there are some weird package interaction going on the version recommended by the Burst team should be the one we should be using.
I’m specially interested in finding out if there actually is some weird interaction, so that I can dodge it.
You probably have a package installed that has a dependency on Burst 1.6.6. I think you can go higher than the “recommended” version manually, but not lower for as long as a package requires a specific (minimum) version of another package.
Could also be built-in, ie specific Unity versions require specific minimum versions of a package, or rather the other way around: for example Burst package may specify that if installed in Unity version x y z that it needs to be installed as version a b c as a minimum, because older versions are not compatible with that specific Unity version - though that’s just a guess.
I have several packages that show dependence to older than the newest Burst version… but I always assumed that was a minimum version and not a specific one. Also, only one of them has burst 1.6.6 listed, the other ones are older; so I’m still a bit confused on what’s happening “behind the scene”.
The reason you are seeing 1.6.6 in your version of the editor rather than 1.7.4 is an effect of Unity’s package development lifecycle, which focuses on delivering packages tailored for specific Editor versions. When an editor enters the “f” phase of a release line, focus is put on stability, including feature stability. Doubly so for the LTS stage of an editor’s lifecycle. For this reason, newer versions of a package that introduce new features or modify existing features are not proposed as upgrades. Behind the scenes, this is implemented with a hard-coded list in each Editor release with all packages offered by Unity and the version that is pinned for that Editor.
So it’s nothing “weird” that is causing this situation and unfortunately, not really something you can prevent/dodge either. The good news is that you can still manually update the package to 1.7.4 by updating your project manifest (Packages/manifest.json) directly, for instance, but at the same time I fully realize that this is far from ideal UX, and it’s probably not the answer you were hoping for.
I’d like to add that your feedback is always welcome and something we count on to improve the features offered by Unity. Thank you for reaching out!
What I was worried was happening is that 1.7.4 had some interdependency with other package versions and that would cause me problems; if that’s not the case and it has more to do with extensive internal testing being done for a specific package configuration and that being set as the default (or something simmilar) then that’s all good.
Also, while installing newer versions of a package could be improved upon on the package manager, you can do it from the package manager without needing to edit the manifest, by using “Add package by name” you can set a version and it gets added no problem.
