The sad thing is that the blog post is believed by many users. Those who know that Unity isn’t being completely honest don’t even have the opportunity (as before) to write something directly under the blog post.
Unity shouldn’t be surprised why some people write that they give the shareholders more priority than the developers.
Yes, many people are asking about FSR2. Although it is desired and would suit Unity better because of its higher platform independence, Unity is more likely to choose DLSS3.
It might get even better. They will only partially implement DLSS 3. Who cares about details? if you can write later that you also support DLSS3.
I’m not doing gamedev right now so I have no dog in this fight, but this is farcical. You need to draw a line under the current version numbering system and start fresh. Either rename 2023.3 to 2024.1 and 2023.LTS to 2024.LTS or switch to normal numbered versions, maybe even numbers for LTS and odd numbers for Tech Streams.
1 Like
I’d prefer to have both. The current FSR fallback for devices that don’t support DLSS is jarring. FSR 1 is very poor quality.
Just semantic versioning would be best. It’s how a lot of software works.
1 Like
I’m all for a more logical versioning convention, but even if the version year lined up with the actual year or going back to the original arbitrary number format, it’s all fairly insignificant really. The main issue is the LTS cycle blowing out much longer.
@LeonhardP nice blog post, but are there any more details about things like “Improved graphic performance”? We’re pretty consistently hitting a wall with CPU performance in URP despite our best efforts. We might consider moving to the tech stream if there are significant improvements there. How/when/where can we see your profiling to show said improvements?
Thanks!
1 Like
Hi Strich, with RenderGraph, the focus is on automatically optimizing GPU performance for Tile Based / Mobile GPUs when you extend URP with custom RenderFeatures. We are also working on a number of main thread CPU optimizations but it’s not clear yet what use cases will benefit and to what extend.
3 Likes
Hi AljoshaD. Can u also check case IN-52428 to make sure Entities Graphics is working nicely with this latest URP with solid 60 fps at least at snadragon 855 android phone at Unity 2023.3? Currently 2022.3 is perform poorly and I hope this performance issue will be fully addressed at Unity 2023.3
Good feedback. A few comments:
- In terms of “getting things into your hands sooner” - we are actually talking about a few features that were originally scheduled for the 2024 cycle but we’ve brought forward into 2023. That means they will be in 2023.3, yes, but more importantly, it means they’ll be in 2023 LTS.
Even though that LTS is being pushed out a bit, it still means you’ll have a production ready version of those features sooner than if you had to wait until the 2024 cycle.
And for those 2023 features that you might have been looking forward to in the LTS - the 23.3 tech stream will be fully supported and production ready.
- We understand the frustration around the extension and also about naming. I have been looking at naming internally for a long time now (too long), and we are always evaluating how and when we could change naming schemes to make it simpler. Nothing to share but your comments here are valuable as I can merge them into the current evaluation/proposals.
Thanks!
3 Likes
Hi all,
I replied directly to a comment but realized after there were a few of you asking about this.
Product naming.
Turns out it’s a hot topic, so I wanted to outline where we’re at.
First - I agree with you. Naming is not ideal at this moment. We’ve been assessing internally on naming for a while now and are looking at what we can do without having significant impact on existing creators and our internal dev teams.
The logic of the current naming scheme:
-
we wanted to recognize when the bulk of the actual dev work is done.
-
let’s use 2022 as an example. We start doing the first alphas in 2021. The first beta was released late 2021. Then in 2022, we released 2022.1 tech, 2022.2 beta, and 2022.2 tech. We lock feature development after the last tech stream, so from that point until the LTS is released - 2022.3 - we only focus on stability and performance, with no breaking changes allowed and no new features added.
-
So, while 2022 LTS was released later in 2023 than we’d like, it still recognizes that the bulk of the work, and the new features, changes, modifications, were all done in 2022.
-
This is an important distinction. For example, if we called it Unity 2023 when we released it earlier this year, some creators might ask why it didn’t support the new apple devices right out of the box. Clearly marking that any new development work was “complete” in 2022, helps define what platform support we have locked in.
-
Those names are really just “product” names (or marketing titles if you want to make me sad). From a development perspective, our naming is actually stuff like 2022.2.7f1. LTS is always year.3.0f1. For example, the latest 2021 LTS version is 2021.3.29f1. You can even find branches if you’re in certain programs like I had with DOTS - 2020.2.2f1-dots.4. The letter indicates what kind of release it is, with “f” being “final”. A beta will look like 2023.2.0b5 (the current public beta) and alphas look like 2023.2.0a22 (the current public alpha).
-
So while we could change the “product names” just by saying “do it”, if we want them to match the actual product versions, we would need those to change also. Which would take more effort and dev time to ensure trunk and branches and features are built appropriately, including looking at product-ver flags that may assume the major version number is a four digit year.
-
None of that is impossible, but we do want to be considerate of that change and how it might impact both internally and externally.
We have done quantitative and qualitative analysis on the product name. Anecdotally, we saw results from a poll that indicated roughly half of the respondents were good with the current naming scheme, and half wanted a change.
But when asked what kind of change, the responses varied more than you might expect. Yes, naming the LTS after the year the LTS actually lands was the top of the list, but others asked as some of you have to use a standard version number, some said drop the version number/year number completely, some said use code names for each LTS “Unity LTS JOBLOW”, and other suggestions.
We also interviewed a number of studios, big and small, and got their insight too.
So - where are we? At this point in time, we are using the year naming scheme and following the logic of “call it after the year it was developed”. We ARE assessing the naming scheme, and in particular because we’ve added the third tech stream to this cycle, that evaluation is currently going on to determine a path forward.
For now - it’s 2023.3 and LTS (2023.4).
2 Likes
I have no comment for version naming and current naming scheme looks ok for me. Anyway I just want to know when 2024.1 alpha will start after announcing 2023.3?
With the added time, will more things also get into Unity 2024.x cycle?
Thanks for the reply. Just to clarify something, you mentioned that the 23.3 tech stream will be production ready, but the perception I think many have (myself included) is that it’s safer to wait for the LTS. The tech stream might be considered production ready, but obviously there’s still room for major changes and the issues that can arise from that.
I understand the engine is so vast now with countless features all being developed alongside each other, and that there’s no way you could say with any certainty that the 23.3 tech stream will be as solid as it would have been if it were the LTS, but that’s all we’re after, we need certainty that when we upgrade that we’re not going to be backed into a corner with an engine that ends up having major issues and prevents us getting our games to market while we wait for bug fixes.
So I’m still just feeling extremely uncertain about using a tech stream, but if there are any reassurances you can spreak to regarding a tech stream being used for production that would be great to know. It seems that would be a contradiction to the LTS version, but could it just be that our perception of the LTS and lack of certainty on using a tech steam for production is misplaced? or are there any assumptions we can make about a .3 tech release being more stable than a .1 or .2? or perhaps even waiting for a new tech stream being out for a couple of months to iron our initial bugs.
The short version is how do we identify stability if it’s not an LTS version? thanks!
1 Like
We’re in the same place as @jason_yak - we moved to using LTS versions a few years ago and have been avoiding tech releases for stuff in production, or alphas/betas for anything at all really. They’ve just been too unstable to rely on and the relative stability of LTS versions has been much easier to deal with.
The issues do really hit when something like URP is in lock-step with a Unity version and the older versions of URP don’t seem to have issues addressed/fixed or receive much attention at all. This is hitting us quite badly in the current 2021 LTS at the moment, and the 2022 LTS is even more broken. So, we’re even between a rock and a hard place with LTS versions, let alone thinking about using a tech stream version.
Hopefully the 2022/2023 tech and LTS development cycle goes well given the long time before a 2023 LTS lands.
The problem is those terms mean nothing any more. Going by all your editor and feature releases in the past, say, 5-10 years, “production ready” just means beta and “fully supported” means “after you make a minimal repro, produce a video and jump through numerous hoops the QA will put you through, there is a small chance a blocking bug might get fixed in the next 6 months”.
6 Likes
NRP support for XR was added indeed and will be part of 23.3.
1 Like
Awesome!
Looking forward to testing it on standalone vr
It would also help if you could, for example, introduce colors for the individual years in the Unity Hub. I only see numbers and sometimes I have to look 3 times so I don’t get the wrong version. Before you even had to make sure that it wasn’t a 2019 version because there were 3 tech streams. Now the nonsense starts again. Now you have to take a closer look and know exactly from which year the new system was introduced. Of course people will complain again and in a few years you want to change it again?
After an accident has happened, one should not keep trying to improve the situation so that this accident does not happen. After the accident, the parameters are different.
Unity, you guys are really not good at UX.
Actually the actual problem behind it is not about year naming scheme but the editor stability and breaking changes. Currently according to case IN-44206 even at latest 2022.3.8f1 LTS at the time of writing, it still has serious player runtime building issue that make the build process really pain that u can’t 100% guarantee u can successfully get a game build after pressing build button. Then for breaking changes what I know is at URP there’s always has breaking changes that official silently change it without documentation to clearly mention those breaking changes and the resolution to fix those breaking changes. I guess that’s why asset store developer tired of keep spending time to figure out the fix themselves and delay update to LTS version.
So the expectation is to bring editor stability improvement, reduce breaking changes and clear documentation to breaking changes to next level. For each tech stream, it needs to reach quality bar higher than current LTS that should not happen issue like case IN-44206 that can fail player runtime building which unacceptable.
Visual Studio 2022 is really 17.X so I don’t think the year matters too much. Contrary to the marketing BS blogpost, I’d guess this extra tech stream is more about them falling behind combined with needing a full year to stabilize the .NET CLR scripting change. Which is my last chance for Unity so I hope they do it right. Tech streams are glorified betas regardless how Unity labels them. So whatever the latest LTS is is all that really matter to a lot of devs.