I agree legacy UI is still faster than UI Toolkit at the start, and for small projects but UI Toolkit has a lot of benefits when the project starts to grow, far easier to edit some UI without worrying about code and Prefabs dependency, than is just a matter of learning a new system and wait for the feature parity, which is nearly there.
5 Likes
Exactly, at the current moment there is a hard dependacy for the UGUI package. So if your entire project uses UI Toolkit you are stuck with extra stuff being added to your builds in most cases even when not using it.
6.5 
From what I recall every third minor release is now going to be an LTS. I got confused above since I didn’t consider that we started numbering versions with “0”.
So it’s going to be:
6.0 LTS
6.1
6.2
6.3 LTS
6.4
6.5
6.6 LTS
6.7
6.8
6.9 LTS
…
Hopefully we won’t see a 6.10 as this would confuse a lot of people (myself included).
2 Likes
Isn’t the dependency only due to the URP debug menu I a) don’t want and b) keep opening by mistake?
Because you can burn that with fire in 6.4 and make everybody’s lives better. Or at least slap it behind a #if UNITY_UI and call it a day. I don’t know why it exists.
6 Likes
+1. I generally don’t understand why, given the pace at which the UI Toolkit is developing now, we still can’t use IT ALONE, because of the very strange dependence on URP. I was hoping that it would finally be burned out in 6.3, but now it looks like we’ll have to wait at least another six months to 6.5 for it to finally happen.
This is actually something that seems like it can be done with very little effort, and that will make life much easier, since the Unity UI package is currently cluttering up context menus too much.
Well that is a long way of getting to 7.
When do we see the CoreCLR and .NET Modernization phase start with those versions given it’s it is like a year between LTS versions
3 Likes
My list is just an example. I don’t know whether there will be a 6.7 or whether 6.5 might become the next LTS if the series turns out not to be strictly ‘+3’.
You think this is not confusing already? 
Even my most advanced teams do not want to use Toolkit and either opt for their own solution or try to find something expandable enough in the store.
Eventually this will change but it has already taken too much time… and imo too much time wasted… they could have refactored and optimized the existing UI system in all this time and it would be far better than Toolkit.
Amateurs do not want to touch UI Toolkit, it is not designer friendly and that is an onboarding problem.
Even when it will ever be finalized, UI Toolkit, (judging from the persistence in this feature design philosophy despite years of complaints,) will always be undesireable I can almost guarantee it.
2 Likes
When you make a build, we analyze the assets and components you’re using, starting from some ‘roots’ (like the scenes in the build, the Resources folder, etc) and following the dependencies, transitively. Assets which are not reachable from any roots are not included in the build. Similarly, managed code stripping can be used to remove unused code. The net result should be that if you’re not using uGUI in your project, it doesn’t add bytes to your builds, even if it’s present in the project.
Having it in the project is still annoying at Editor-time and creates opportunities for using it by accident, etc, which is why we still plan to eliminate the dependency, but it shouldn’t be impacting your built games today.
8 Likes
We’ll keep doing 6.x releases until we find ourselves in a position where we need to make a big enough breaking change that a 7.0 is justified.
We are also not committing to a strict ‘every 3 releases’ cadence for LTS. I think you can expect there to generally be 1 LTS chain starting per calendar year, but that may or may not be ‘every 3rd release.’
5 Likes
I’m not sure that RichardFine will be happy that this discussion will turn into another “UI Toolkit is not needed”, rather than a discussion of critical changes in Unity 6.4.
We are not talking about removing Unity UI package. We’re talking about the fact that the URP package now depends on the Unity UI package, which is why even projects that use only the UI Toolkit can’t get rid of it. And this is a significant problem - Unity UI clutters up context menus too much and creates a lot of visual garbage where you would not like to see it from the word at all. Eliminating this addiction won’t change literally anything for you.
5 Likes
Good point. Let’s wind up this subthread and get back on topic! 
9 Likes
So 7 will never come
1 Like
I hope UxmlAttributeAttribute should be remaned to UxmlValueAttribute or something else
1 Like
I know U7 already exist as internal for years
But it also has been like that for years. And we had hope it would came out last year then it’s not
Which can be repeated this year. And next year. And next 2 years. And next 10 years
Public Alpha branch will be unity 6.4.0a. 6.5.0a. 6.9.0a. 6.99.0a. 6.999.0a
That’s the meaning
1 Like
Such early removal of Compatiblity Mode sounds like a catastrophic change
My 2c: With 6.3 being LTS you will have two years of support for a version of the editor that has compatibility mode. I don’t think it is a short timeframe for such a change. For new projects starting on 6.3 you shouldn’t even enable it given the fact that it will go away in the next version and you’ll probably upgrade the editor until you release the game so you will have to deal with it eventually.
2 Likes
RenderGraph is much better API than old “compatibility mode”. In early days there were bugs, but now everything works as it should. I strongly recommend to rewrite passes from old api to RenderGraph and switch as soon as possible.
The problem is you can’t have both APIs active at the same time, so all passes need use either RenderGraph or old mode. AssetStore developers must support both. The sooner it’s depracated the better.
11 Likes