Suggestions about Unity New Versions

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.

 

IMHO they need a better branding of the LTS version, aka real deal vs tinkering.

When I introduce people to unity, they don't get there is tiers, aka beta, demo (tinkering), then LTS (real deal), they just increment whatever new version they can, which like I learn not to, especially in ongoing project. New people should only see the real deal version of each years, advance user should be informed of the tinkering version and aware of the beta.

Right it just feel like fragmented mess, especially when you add small revision within each tiers. It also makes it hard to track features. Also new features should be DONE, not announced, for each version, except beta.

But to be frank unity rn feels like endless beta anyway, it wouldn't matter in practice.

 

LTS is a common software lifecycle term. TECH is the real troublemaker in my opinion as it doesn't already have a meaning associated with it.

https://en.wikipedia.org/wiki/Long-term_support

 

Sure, but maybe it should be even more emphasized that LTS is the version to use. Because now we have people making Android games with 2019.x using the latest features, and then wondering why their games are broken on a whole bunch of devices.

Personally, I would push all naming down a tier.

LTS is just the released version.
Tech is beta.

 

No, LTS is the Long Term Support version. Tech is still perfectly acceptable for releases. LTS just means the features are locked.

 

Long term as opposed to what? No support at all? When a new tech release is released, the older one is no longer supported within a month. Other software that have LTS versions are to differentiate between having support for a year vs 5 years in LTS. In Unity it's supported vs not supported.

And there are many platforms where Tech releases are simply unusable.

 

Then you do your research and don't release on those platforms. Half the people posting here can barely find the right forum to post on. You can't hold Unity accountable for them not actually looking into what to use.

 

I'm just saying LTS -> Release and Tech -> Beta would make more sense (to me), and would drive more people to use LTS, which, IMO, would be a good thing. I'm not really blaming Unity for anything. (at least not in these last 3 posts)

 

Except it wouldn't because now the beta and alpha branches that exist make no sense.

 

That's not the way it is intended. TECH releases are intended for developing a project from the prototype stages up to the point where it no longer will be receiving new features at which point you switch to LTS releases.

This isn't a problem with naming. This is a problem with Unity releasing before it's actually ready.

 

The easiest way to fix that disconnect though is to change the naming.

 

That's just masking the problem.

 

I disagree.

At the very least, it would stop people telling me "but Tech releases are just as stable as LTS, they are just not supported long term", when I say I don't want to upgrade to a Tech release to get a bug fix that wasn't backported to LTS.

"beta is just as stable release" would sound a bit ridiculous, right?

 

You realise all of these reasons were why we switched to the current system, right?

There is no pressure on Unity to release new features for the yearly version. Instead features get released when they are ready, in whatever version happens to be scheduled for the next release. (We can argue about Unity's definition of ready. But that's a completely separate issue to the versioning question.) Years aren't major versions anymore. Nor are the .x minor releases. Every release is an incremental release.

In reality your system would be going backwards. Unique names would be very similar to the old major and minor version system. Major features were frequently delayed or released early, simply to justify releasing a new version. This was particularly bad with Unity 5, which is why the major version system was abandoned.

As an exercise, in your system what exactly will justify switching from Unity Star to Unity Galaxy?

 

Anyway I'm now presenting stuff to new people as:
1. locked, features "complete", that is LTS, Ie the stable version to use for them, fully documented.
2. indev, all the version below where feature are added progressively, ie avoid because features are morphing, it's intended for people who can adapted to change made, and wade through the scattered informations.

Yeah just a clarification in the naming to correctly funnel people and manage their expectation. Clarity is still an important thing.

 

Personally, I like the year and version system. It's very straight forward. I have a bunch of other programs to keep track of, and I don't want to spend time figuring out which of the names is what.

 

1) Programmers are not completely fungible.
2) Adding more developers to something doesn't scale up linearly and infinitely. Ie: if something is going to take two weeks with one dev, you can't just assign 80 people to it and have it done in an hour.
So there's an upper limit where adding more people on a given task has no benefit, and well before that it has significantly decreasing benefits.

Now add:
3) While DX12 is a critical feature for you, it's not the only feature people care about.
Most Unity users would not be pleased to hear that the features they're using will be delayed for months so that DX12 (which may be irrelevant to them) can get done 1% faster.

 

I agree with much of what you said here. I do still strongly believe there are a few core features that need to be polished to production level. My short list would include DirectX12, Vulkan, Gfx Jobs, and 64 bit resource files in builds. I do realize that everybody has a slightly different list.

Part of the problem at this point is that very few developers are using DirectX12 or Vulkan with Unity, because those features are currently not production ready. Since very few developers are using those features, Unity's stats probably allow some decision makers to think those features are not important. But the reality is that developers would use those features if those features were production ready.

Back to the version naming, I personally really love the year based version naming system. As I mentioned earlier in this thread, the reason some people are unhappy with the current version naming is because there is a disconnect between developer expectations and what Unity has delivered. A lot of developers are expecting the .4 (LTS) builds to include production ready features. Whether that expectation is fair or not is definitely a valid debate. Either way, that expectation is resulting in threads like this one.

Maybe Unity needs to post something explaining why certain features need a few more years to get to production ready status. That would help line up developer expectations with progress on those features.

 

What with DOTS, new UI and the new render pipelines, I feel like they should do a Unity v2.
This strips out all legacy, soon to be legacy, stuff and focuses on the new tech.

The code base must me a huge mess of legacy support and in-dev features right now!

Edit: /s missed, but I can dream

 

I think that would be counterproductive and a step backwards. It would segment the userbase, and make it harder to get developers to use the latest version. Remember, Unity used to do releases that way years ago from Unity 1.0 through Unity 5.6. The wiki article lists Unity major versions along with the release dates for each:
https://en.wikipedia.org/wiki/Unity_(game_engine)

 

Honestly its the same as adding new features. Legacy features should be removed gradually as they are ready to be removed. It would be a massive disservice to remove all legacy features at once regardless of the next solution being ready or not.

 

Cough cough URP

 

You people are really being unfairly negative towards the OP and the ones that agreed with him. Yes, big software is not easy to maintain, let alone expand, but this is not a valid reason to ignore the problems that are present in Unity.

Is it really that difficult to see why aadil50 and ShilohGames want Unity to build a better foundation, before ticking more buzzword checkboxes? Surely there have not been any cases where something Unity has built collapsed on itself Unet

 

Unity Galaxy sounds out of this world, and is my vote.

 

His suggestion is literally "let's switch away from a numbering scheme that is confusing to some people new to the engine to one that will be confusing to everyone". To be blunt the suggestion is stupid to the point that it's very difficult to believe he's serious.

Are you telling me there are people who think switching from a version numbering scheme to a nonsensical scheme is a smart decision? I mean I suppose it's always possible they genuinely believe it's a smart decision, but I have to wonder if they likewise believe in perpetual motion, a flat earth, and that the moon landings were faked.

 

None of us disagree with this sentiment. There are plenty of foundational features that would do well to be improved. And Unity is working on them.

What we disagree with is that changing back to major versions instead of incremental versions would make any difference to this process.

 

I agree, but Linux distros go by this convention.

Take ubuntu for e.g

 

Linux distros like to have a secondary name that changes but that doesn't mean they throw away the version. Ubuntu's latest release for example is Ubuntu Eoan Ermine 19.10. His suggestion as I understood it was to remove the version.

 

Ah, well you could OC tag on the version number. Just think, we could have noobs joining the forums saying I'm currently using Unity Galaxy, and we'd all be like 'Yup they must mean v2019.1.2.3.'

It would be win win

Someone has already gone to the trouble for us.

Spoiler

https://codepen.io/semibran/pen/wazzaj

 

How would you call U Galaxy 2.1b4223 for such newbies?

A: Hey what version you have?
B: Milkyway.
A: But is LTS, alpha, or beta?
B: I don't know, it doesn't say. It just says Milkyway.
A: Check Help -> About Unity.
B: Ok, so it Unity Milkyway 20xx.2.0a1234
A: You need LTS then.
B: Which one is it?
A: Unity Andromeda.
B: Will it Andromeda get same features as Milkyway?
A: Yes when they collide in 5bln years, they will become one.