Feedback Why Unity just skip a version?

Hello,

Instead of starting Unity 2023.1.0 beta, skip a version and start Unity 2024.1.0f1 final.

 

Why stop at 2024? Go for 2025!

 

Yea, i mean, i love these versions that dont even make sense with a year that doesnt exist. Already ridiculous enough imo. Meanwhile, LTS versions see the same issue across EVERY LTS, unfixed. It is what it is.

 

I see this kind of question earnestly asked a lot on Reddit and other forums. I think @AlanMattano already knows the answer and is just joking around. To avoid confusion for all the people who will find this... odd... suggestion later by a google search...

Every year, Unity starts a new feature branch for that year. Large new features are aimed at these branches. That will be <year>.1 and will mature to <year>.2 and eventually <year>.3 LTS, but this process takes more than a full calendar year. Thus, annual feature branches overlap significantly even in the best of times.

The current LTS is way back at 2021.3.something and is the latest supposedly production-ready platform which is recommended for users to actually make their games.

The 2022 feature branch is still in the .2 maturity phase. It needs significant work at the moment to be called a 2022.3 LTS, and is not recommended. Anything less than an LTS version is for users to experiment with janky broken introductory features, to evaluate whether the new features will be useful, to report issues and monitor the development. They're not intended or recommended for users to actually make their games. As always, make backups and only try a new build of Unity with a scratch copy of your project, as bugs can damage your assets and scripts in ways that can't be downgraded.

It's March 2023. It would seem like a good time to start a 2023.1 branch, and surely Unity staff have been laying that groundwork, but given the poor maturity of 2022.2 at this stage, they're probably hammering on that. There's still the IPO and Iron Forge &%#@! integrations and the tech world is all abuzz about layoffs, so they're arguably behind their usual cadence.

Since it's not 2024 yet, there's no 2024.1. And the last part, the .0f1 of your suggestion is clearly part of the humor, it indicates a finality to the 2024.1 branch on the very first build, which is just nonsense. However, if the 2022.2 and the staffing issues remain as rough as it currently stands, it's not ludicrous to suggest skipping 2023 entirely, but I doubt that's their intention.

 

Unity 2023.1 is in beta atm: https://unity.com/releases/editor/beta/2023.1.0b7

If you haven't yet, you should try it for the new Awaitable class that lets you wait for end of frame or return to the main thread without the need of a MonoBehaviour class.

 

Having a yearly release schedule is simply the stupidest decision ever.

We went from "having to hold back features for major releases" (which I guess was bad or something?) to "just release some S*** because it's time".

Which also makes LTS a joke. It's "supported" for 2 years, but it's actually 1 year, since LTS needs 1 extra year of dev to actually be somewhat stable.

Drop the yearly schedule Unity, it's a bad idea in general and you most certainly can't pull it off.

Also fire whoever thought yearly releases are a good idea.

 

The main reason why Unity shifted away from big number releases/upgrade (3.0, 4.0, 5.0, etc) is because it doesn't fit the subscription business model (which Unity shifted to around the time they went to yearly updates with 2017 etc).

 

Yearly releases also lead to some predictability and it should serve as motivation for the devs to push forward.
Not wanna end up with 9 years on one major version like how Unreal Engine 4 lasted.

 

Pretty sure there exists a middle ground where you can have releases more often, without being bound to a yearly schedule that you cannot keep without compromising the quality of your releases.

Yeah. predictably buggy releases no one wants to use.

Because that is Unity's problem, lack of dev motivation... right.

 

You want Unity to release major versions more often? Whats your proposal?

 

If you use sematic versioning, every version that has breaking changes would mean a new major version, with the current development there would then be 2 major versions per year (initially 3). We would now be at Unity 20 (rough estimate)

 

Hello Legend,

I like the year version idea but not how Unity implements them.

In other words, what is the point of having Years if you do not use them?​

It is confusing for a new user that needs to learn in a stable release.

A 2023 project? I'm using Unity 2023LTS (3.40)!​

Aaa... no no, is Unity way. And that turns out to be "

"

 

Why is it unituitive that a Long Term Support version is based on a non-actual version of the software and thus has an old year number?

 

Yes, I agree that it is confusing. I was merely stating why the company transitioned to this year-based version system.