As we already know, Unity has LTS release versions, and it’s two-years long term support… but, I do really think it should be just one-year long term support… let me explain why…
Unity Tech-Release version has been more stable than ever, and an LTS-Release version makes it even more stable…
Adding to that one more year makes it even much more stable and ready for long term development(which is important), however, Adding to that YET Another More year is really unnecessary.
Benefits we’ll get from doing this:
• Focusing less on so many LTS release versions simultaneously(e.g. 2017.4, 2018.4, 2019,4, 2020.3 etc), by finishing them faster, which speeds-up the development workflow. • Saves up time on the long- run to focus more on Tech-Release versions which results in more features and improvement to the engine. • Makes it more convenient for the user to upgrade from one lts to a newer one faster and get richer experience. • Speeding-up the process for making a lot of preview/experimental packages that were never pushed to “Release” get verified much quicker. And So Much More.
I think Unity has really to consider this at least in its Roadmap. So, Share your thoughts and tell what you think!
[quote]
Unity Tech-Release version has been more stable than ever
[/quote]This is false.
The solution to the problem is for them to stop the yearly development cycle, but they can’t really do that with a subscription model, so first we should get rid of subscriptions.
Other than that, making their only usable version be viable for less time is very silly.
There are different target audiences here, but for my company and me, Unity and especially most of the packages feel unstable. We’d prefer fewer features and more stability.
I can also imagine that for many users the ecosystem is hard to navigate. There are LTS, beta and alpha engines. Then we have experimental, preview, pre-release, regular and verified package versions. Some of them are recommended. Sometimes the labels change depending on the version setup you have installed or which version of the documentation your browsing. It feels a little messy with all of the warnings about experimental features, etc, but in the end we have the impression that the final products are less stable than they used to be in Unity 4 - 2018.
It is good for a project to freeze software versions as early as possible, unless a new feature has a major benefit. Two years is a common development cycle, so it seems reasonable for LTS to last that long. Shorter will have relatively small advantages for Unity, but relatively large disadvantages for a large number of developers.
Imagine you’re building a product like a car configurator that’s being deployed into thousands of retail stores around the world. Attach that to a complex backend system where the car manufacturer can deploy new vehicles as needed (with all accessories, trim levels, equipment, paint colors etc) - cost to build might land somewhere around the 2 million USD mark (lot of cars, lot of UI, lot of systems to maintain) with quite a lot of custom engineering in there to make all the different SKUs, configuration and unique equipment / regulatory requirements for each different country etc etc and the plan is for that product to live for minimum 5 years. As the effort for initial build is so large you’re only going to land the sale of such an endeavour with said car company if ongoing maintenance can be kept low because the platform is super stable.
Now tell me how long you want Unity to support the version of LTS you pick as your go live platform.
A ~lot~ of people use Unity very differently than what you might think.
Thank you guys for your comments, opinions, and suggestions! Much appreciated.
Ok, I just figured out that Unity has dropped version .3 for every year release as a tech one, and instead, made it as LTS… Now with That being happened, they’ll deal with much fewer features every year, which equals to, much less bugs… which supports my whole point now for making Unity LTS a one-year support… it’ll be More than enough right now…
We want much more new features and improvements made to the engine, so we can also close the gap of features as a competent engine against (e.g. Unreal Engine…)
Yeah, because previously, Unity had three tech releases a year, with 2 years LTS, and even those 2 years of LTS, they Couldn’t squash every bug in the engine for that year (e.g. Look at the latest 2017.4 or 2018.4 version in the release notes, they still have bugs), because let’s face it, it’s almost impossible to destroy every bug out there… and keep in mind, those two years of LTS was being made to Three tech releases…
Now, my point is, they just Dropped a Whole Tech Release Version… So, Making LTS a one-year long is almost the same as before with three tech releases and 2 year-support, because much less features a year = much less bugs anyways… making Unity perfect and free from bugs is almost impossible anyways… so, why not make it a one-year support knowing there are two tech ones right now? That really makes sense…
This is false? Each Tech release doesn’t have its own LTS, or I don’t understand what you mean.
Edit: I guess you mean, since there are 2 tech releases instead of 3, the amount of new features is less, so LTS should be more stable by default? I still don’t think that’s true.
No it doesn’t make sense.
And if Unity can’t keep up with yearly releases, they shouldn’t do yearly releases, but they absolutely should have versions that they’re supposed to support for at least two years.
Yeah, but I don’t think having Tech twice a year instead of thrice, automatically means less bugs for LTS to fix and also support is not only about bugs, it’s about “hey iOS now has a new requirement that needs changes from Unity, but sadly the LTS I’m using is no longer supported, so I’m screwed”.
Yeah, I agree with you regarding the “new requirements” and stuff… but, in the other way around, don’t you see Unity with much less features = much less bugs? I’m really interested on the way you think…
Oh, that? Well, to be honest, I love both of them, but I tend to be more on the Unity side, that’s why I really want to make it a better product for everyone (:
note 2017 and 2018 are no longer LTS as the two year support ended
unity asset store will only let new assets be summited from 2019.4 or higher
recommend just say goodbye to anything lower than 2019.4
LTS i believe mainly focuses on fix bugs and does not add any new features
it is a fine line between fix bugs and add new features, some new features can fix old bugs however LTS users will never get them
when a bug fix is rolled out in LTS in many cases it does not roll down thru ever year/version within that LTS group, many of the bug fix only get applied in the latest LTS so this sort of makes LTS pointless
a good example of the term tech release can be found in api 8x. this api was built off a unity core in lower 7x and never even received 1/3 of the updates 7x did making it even less advance that 7x… i believe the term tech release in unity started shortly after that failure was recognized
No, not necessarily; Because you need much more Unity team developers to make that happen, as it’s the same for having 4 tech releases a year (1 per 3 months)…
You are given much less time to develop for that Unity year, and then you focus on LTS… shorter time for tech = much less features, which also equals much less bugs as already mentioned…
How?
2020.2, the last Tech for 2020, was released in January 2021 → Then LTS in March 2021.
2019.3, the last Tech for 2019, was released in January 2020 → Then LTS in June 2020.
2018.3, the last Tech for 2018, was released in December 2018 → Then LTS in May 2019.
Where is the extra time spent on LTS?
They made Tech releases from 3 to 2 to have to spend less time preparing for releases, not to spend more time on LTS.
And even then. The amount of bugs doesn’t really matter for support. It’s not what it’s for, but I’ve already said that and you shrugged it away.
IMO, they should drop the yearly releases and just release stuff when they’re ready. They should also stop Tech releases in general.
Just release a version when you feel it is good enough, then support it until you release another version (could be 2 years later, could be less, could be more) +1 more year of support.
LTS releases should really be thought of as promises, because that’s what businesses need to make decisions and plan ahead. We can’t base a business plan on lucky guesses. Just some of multiple factors:
If we release a game in 18 months, we need to be sure that the engine will still be compatible with supported platforms (just think of consoles which might add special requirements next year)
Even if our production is only 6 months, we want to maintain our game for a reasonable amount of time.
Two years is good compromise here. Most Unity projects will be developed within that time frame and it’s a valid time to keep pushing updates to a game without being concerned too much about changing engine tech.
If the project takes longer than two years to develop or the game is live for more than that, it’s a reasonable time frame to be updating the engine.
You could also look at this from a stabilization point of view: The more time Unity spends on fixing issues, the more stable it will be. As most people know, you can’t build software faster by throwing more people at it, maybe you can optimize a few processes and make good design decision, but to fix mistakes, you simply need time. So for stability, I’d prefer a battle tested two year old version.
The tech stream releases are where Unity doesn’t need to make promises, so they don’t even need to lock it down to a specific number of releases per year, I agree. As long as they support their most recent LTS for at least two years or until the new LTS is ready, they can pump out as many or few as their project management allows.
As you may already know, Unity releases a major release (e.g. .1, .2, .3 etc) every three months, and even after the dropping of .3 and making it LTS, the schedule is still the same, the first two (.1, .2) are still scheduled every three months, so it’s the same time as it was when they were three tech ones… hence how. Almost the same amount of features and improvements will be made in the first half of a year… and then, the focus goes to LTS after .2 is dropped…
So, it’s the same given time (6 months), not more, but much less than (9 months)…
I’m not sure what you mean by this, sorry… can you be clearer, please?
