I recently look around Unity 2020.1 Alpha version, I am not surprised because every year changed Unity brought us new Unity with a new name yearly name. So I thought what about older version fixes, bugs and supports. Eventually an idea come through my mind why not to discuss with other unity users here, that we should request Unity to not bring other Unity yearly name. Because it will become necessary for them to bring a new unity every year and they will be busy in that and forget older version [due to distraction] fixes, features and almost every thing. So My point is that we all should make a campaign that reach Unity CEO about new Unity Version names. It must name like Unity Galaxy, Unity Star, Unity Plasma, Unity Ultra, Unity ABC, Unity XYZ, etc… further more you can suggest or they can decide within their management. So what will be benefit of this? Competition of low time [every year a new version is must] will be reduced, Older version will get attention, and many more head aches… They will start a new era of Unity XYZ with number version which may last 2-3 years with adding features and bug fixes. And after some extent they will release LTS which may be take for upto 5 years. And will be more stable with all platforms compatibility. Fixes older versions and may be merging all versions like Unity 3,4,5,2017,2018,2019. If any one agree with me please promote my vision about Unity. It may be good for Unity,Developers,Business point of view… Thanks a lot…
jebus, no. its a games and visualisation tool, not a kids’ anime.
silly premise, shows zero insight into everything UT indicated when they went to year-based versioning in the first place, or their actual release practices
This is the worst idea I’ve seen all month.
What is silly in this idea can you explain it?
My Point is about not to update every year by changing just name…Update Monthly but with all possible fixes… Just read release notes you will notice dozens of Known Issues… Instead of giving time to new version named with year they must solve the known bugs/issues then got new update…Although I appreciate greatly new features day by day… but what about dozens errors [Specially build errors for mobile] ,crashes on Unity Answers . I want that unity answers must be purely for difficult logical issues not for Software based bugs… for exploring good features which many of us dont know… I know that with every engine or software the bugs are must but the company must pay some attention to these bugs as well… But instead of solving there you are forced to install new unity for compatibility and modern day functionalities…
I was just using example any one can name it… I like when unity 3,4,5 name but after competition is increased with one of an engine in market they started Unity 2017,2018,2019,and 2020… what about 100s errors/crashes/bugs/compatibility issues in the previous 4 yearly Unity… Its ok with name but if you think its quite a headache for developer that which unity should i use for starting a project…If there is no errors again i am mentioning build errors specially because my 3-4 projects are late delivered due to build errors; then i have no problem whether it is 2020 Unity 2030 whatever… But i think if the name is not with year then there concentration may not be for new product rather they will concentrate and focus mainly on features not dependent on new Unity but fixes in old current unity which we are using (BTW i know Unity patches but it take 2 years for you to wait for it)… I hope you got my point…
You mean other than the fact it makes it incredibly difficult to tell which version of Unity is which and which may have specific features you need? Or how about the fact that the names are entirely meaningless?
Unity is a game engine, not a toy. It doesn’t need a flashy name and the current version naming system is good because it makes it clear where you are in the release timeline.
Luckily, then, that’s not what is happening.
Because if its named Unity Pink Supra-Ranger Ultra-Commando Next Gen Edition it’ll be possible to have all outstanding bugs fixable within one month.
Lets just file this under ‘zero insight into large-scale software development.’ as well.
Nope. Your point isnt grounded in the reality of large-scale software development cycles.
And you clearly dont understand the point of the LTS builds.
Enjoyable thread for early in the morning. 
And if you need an example of this just look at how people for years referred to this game engine as “Unity 3D” thanks to Unity’s poor choice of URLs when the actual name was always just “Unity”.
Why not do it like Fortnite does? Each major update would be called by seasons. E.g, Unity Season 1, 2 etc.
I actually love the current year based version naming system. It is very intuitive. It is one of the things that Unity has definitely gotten right in recent years.
The problem that currently exists with the versioning is that we expect new features in .1, .2, and .3, and then we expect those features to be stable and ready to use in .4. What is actually happening so far is new features get added in .1, .2, and .3, but the core features don’t get polished to production ready status in .4. The .4 branch has bug fixes, but not production ready polishing of core features. Game developers expect the new features to be production ready in the .4 branch, and Unity is not meeting that expectation.
What I would like to see are core features getting completely implemented and ready for production. I’d start with DirectX12 and Vulkan. Then I would move on to everything else that is half implemented, half busted, in preview, etc.
At this point, Unity has too many major versions with half busted core features, so the tricky part would be to decide which versions deserve production ready DX12 and Vulkan support. Personally, if it was my show, I would stop everything until DX12 and Vulkan were fully production ready in at least versions 2018.4 and 2019.4. Then I would immediately do the same for Gfx Jobs and 64 bit resource files in builds.
Every one here is their own vision about unity naming, majority are agree with unity current numbering system with versions but i think every one is agree at Unity Previous Bugs and Crashes… So I think instead of Name my main focus is to tell unity to fix previous crashes first then bring new features with newer version (Whatever name 
) …
So no new features for the next decade then. Sounds good.
For Epic.
Well, my suggestion regarding stopping everything and fixing several core features would hopefully not take a decade to complete. If it did actually take a decade for Unity to get DirectX12, Vulkan, Gfx Jobs, and 64 bit resource files in builds polished to production ready status, then I question if they are in the right industry. Seriously, it should not take a decade to get those features stable.
Are new features really useful at all if the core features are not stable enough to use? Some new features literally require those core features. For example, Microsoft’s DirectX Raytracing (DXR) is an extension to DirectX12. If Unity cannot get DirectX12 support stable enough to use, then any future DXR support will also be unusable.
You’ve never done any serious software development, have you?
Care to explain why would it be beneficial to anyone if multiple teams would be on the bench while one or two are working on such features?
The current system is the most clear Unity has ever been regarding what version of Unity you should expect to be using. If you need stability, you use the latest LTS. If you need latest/greatest features and you have risk tolerance for some instability, or your release timeline will see the release of the next major LTS a while before your game ships, consider using the latest tech release for now and eventually moving to the next LTS. If you have other more specific requirements or areas of risk, well that’s what release notes and just some testing of your own is for.
Normally, you would want multiple teams working independently on other important sections. However, when core features are not getting polished to production level quality after several years, it is time to pause and figure out why.
Unity needs to figure out how to get DirectX12, Vulkan, Gfx Jobs, and 64 bit resource files in builds polished to production ready status.
When will DirectX12 be production ready in Unity? It was added as preview in Unity 5.x, but is still not production ready today.