Search Unity

With Unity’s evolution to a package-based feature-delivery system, we will reduce the number of TECH stream releases in 2020, while delivering continuous updates for all feature areas throughout the year. 

Since 2018, we have built, tested, and made available three Unity TECH stream releases as well as one Long-Term Support (LTS) release per year, as I explained in this post. Starting in 2020, we will deliver two TECH stream releases per year, followed by the LTS release early the following year. There is no change to the LTS schedule.

In 2020, there will be two TECH stream releases (shown in blue), followed by the 2020 LTS in early 2021.

Quicker fixes delivery of features and enhancements

The change in the frequency of our TECH stream releases is due to the flexibility provided by Unity’s Package Manager. It enables us to decouple many features, APIs and other updates from our TECH stream releases. Thomas Petersen, our VP of Quality explains: “We’re now moving more of our features into packages. This gives us a number of advantages – one of them is that we can easily update or fix issues in an individual feature without having to update the entire codebase, which also stabilizes the Unity core.”

Here are just some of the ways the change in our TECH stream release schedule will benefit the Unity community.

Deeper beta testing, more stability

Our Beta program is well known and we are always grateful to the commitment of the thousands of developers who take part in it. By reducing the number of TECH stream releases per year, beta testers will have more time to evaluate the tools and capabilities of each core beta release and be able to get deeper into them, while we will have more time to address and fix the issues that they report. 

Less work for developers and studios

We are well aware of the time and resource commitment needed to install and upgrade to a new TECH stream version of Unity. While not every developer or studio is in lockstep with our TECH stream releases, some are. With our move from three to two such releases per year, they will only need to integrate a new TECH stream release every six months instead of every four months.

More firepower for non-game industries and use cases

Increasingly, developers outside the world of video and mobile games are using Unity to produce AR/VR apps, real-time 3D experiences, films, and so on for a wide range of use cases and industries such as Automotive, Transportation & Manufacturing, Architecture, Engineering & Construction, and Film, Animation & Cinematics. With more industry-specific Unity features available via packages, they will be able to reach their creative and market goals faster. 

New third-party platforms delivered at any time

Finally, at Unity we have always worked hard to support the widest number of third-party platforms (currently more than 20), allowing developers to output to iOS, PlayStation 4, Oculus, Magic Leap and many more from the same project. Our new TECH stream cycle and package-based approach underscores that commitment. As new hardware and software platforms emerge, Unity developers will have faster access to audiences on the latest innovative devices.

Connecting the DOTS faster

As you may know, the new Data-Oriented Technology Stack for high-performance, multithreaded projects is fundamentally evolving the way developers will build games and applications within Unity. The stack consists of a growing number of packages. Since we are committed to the rapid development and deployment of DOTS technology and tools, developers can take advantage of the latest DOTS features and bug fixes as soon as they’re available. 

For more information

If you’d like more information about our new release cycle, post a question in this forum or leave a comment below. 

22 replies on “Switching to two releases in the 2020 TECH stream”

They can’t stop releasing new features because of 3 pressure points:
– the competition is not sitting idle
– the looming IPO requires them to show forward momentum
– because they’re on a transition to port the entire editor and engine to DOTS, with that comes the nature tendency of wanting to share awesome things, anyone who has made a game knows it is hard to resist :)

I just find it very dishonest that they release a beta version of something and then essentially abandon it. New input system was released in 2016, still not finished.
Baking solutions were being re-made and they are still work in progress.
Shader graph is nigh unusable because it doesn’t provide you with basic nodes, such as lighting information out of the box, which both of it’s alternatives (shaderforge and amplify) give you by default.

So you’re either stuck on an old version that’s not getting the new features, or you have to update your workflow to a new version to get them, but that mean’s you’re updating to more preview features that will never be finished.

The Unity community can be pretty difficult at times. Gross exaggerations after gross exaggerations, angry at everything all the time, self-contradicting in their demands, and a large portion of them don’t have the slightest idea of what they are talking about even though they act as if they are experts. They want you to fix fundamental problems with the engine, but as soon as you give them the fix, they complain that you’ve changed things. They complain that upgrading Unity versions sometimes causes issues, even though Unity is by far the most upgrade-friendly big game engine out there.

So all I’m trying to say is, take these comment sections with a grain of salt, Unity. You’re giving us the best engine there is out there currently, otherwise we wouldn’t be commenting in here. Packages are solving the engine’s bloat & upgradability problems. SRPs are solving the old renderer’s problem of trying to do everything all at once and being great at none of those things. DOTS is solving the performance issue and much more. Etc…

There are people out there who, for some unfathomable reason, do not like to have options. For those people, the vanilla Unity is still there and still supported.

My only criticism would be that I’m not sure if there is value in imposing the “2 releases per year” rule on yourselves. A lot of major software only release new versions whenever they feel like it, and that seems reasonable to me

Yeah, I agree in general.

I think their declared release schedule is good for setting expectations, but beyond that I think setting less arbitrary dates will give better results.

Part of the trouble is that SRPs, Packages and DOTS are huge, long-term investments that are causing a lot of short & medium-term turmoil. They need to ship with these to TECH and LTS streams to get devs using them so that they can evolve with real-world feedback. Everyone wants them to be magically completed within a year of being declared, but that’s just not possible. Unity is scaling up and tackling a lot of problems at once, and so far, the results are promising.

Everyone wants to use the latest and greatest, but smaller dev teams can’t manage this turmoil well, and it’s not clear to them how much it will cost them to use these incomplete features that are technically “production ready” but still under heavy revision.

So, I think it boils down to a communication problem. Do you have fewer than 5 devs and need to ship within the next 18 months? Stay on a last years LTS stream, and don’t transition to the next years LTS stream unless you have 6+ months before shipping.

Are you actively shipping? Stay on LTS and don’t transition to the next year’s LTS unless it’s been out for 3+ months AND has something you need.

Did it occur to you to dedicate one 2020.x version to bug-fixing and performance improvements of existing features only, to catch up with all those issues that exist for so long?

I’m not asking to dedicate one version to bug-fixes every cycle, this would be just an one time thing for now.

I know that your LTS releases are basically bug-fix releases and pretty much what I’m asking for, but there are many issues in your software today and you don’t seem to be able to catch up anymore. Having such bug-fix release should help to get a lot of issues fixed in a short amount of time.

In my opinion, having existing features of today with fewer bugs has higher value than new features with many bugs.

With every new release on Unity is clear the downgrade of the performance, possibly users with highend hardware doenst notice this but for almost users is a big problem, then please update past versions as 2018 and 2019.1

I’ve installed and uninstalled packages using the package manager, personally never had any issue with this. Packages have a list of dependencies, with version numbers. When you download a package, it also automatically installs the correct version of any other packages it depends on. See:

Maybe the implementation is not fail-proof, but it’s not hard to see the *huge* advantage a package-based system is over a large, monolithic codebase, both from maintenance and usability perspectives.

Still no course correction away from the complete mess that is putting everything into separate packages.
This is a horrible usability nightmare for users.
Nothing works reliably with any other package, one has to search together packages for everything, install everything separately manually, search together for everything with which version of which plugin it may theoretically work together.

This is a disastrous direction and it is incredible you are still not realizing this and still not correcting course.

I’ve installed and uninstalled packages using the package manager, personally never had any issue with this. Packages have a list of dependencies, with version numbers. When you download a package, it also automatically installs the correct version of any other packages it depends on. See:

Maybe the implementation is not fail-proof, but it’s not hard to see the *huge* advantage a package-based system is over a large, monolithic codebase, both from maintenance and usability perspectives.

I haven’t had major issues with packages either. Packages were a very good idea if you ask me. Less bloat, more options, easier upgrades, faster releases, etc…..

The time to search for and install packages represents an infinitely small portion of the total time that your project takes. This is not at all an issue for me, and I encourage Unity to continue in this direction

Also keep in mind that an enormous portion of the complaints about “packages not working together” come from people who misuse them

No, the plans for going to two releases has been cooking for a while. We started user surveys about it last GDC.

Why not 1 instead of 2 if it’s a good thing? Why don’t you admit that you just cannot keep up? And many Packages depend on the release. This means that Packages development will slow down as well. You may want to say they are independent but Packages are at preview/out-of-preview at 2019.x release and it’s likely take longer now. Oh well.. whatever.

Note that you have released 2019.3 yesterday (1/28). You mention the 2019 LTS will ship “this Spring” in the blog post. You should probably adjust your chart before you mislead us into believing that there is anything stable but 2018 LTS at the beginning of the year 2020.

Thank you for this… even though I love the improvements we’ve been getting over the last 2 years, trying to keep up with these releases and the (sometimes) breaking changes.. have been a headache. I’d rather less releases of higher quality any day.

No idea why this is needed. In Unreal they simply have version 4.23, 4.24 every few months. There’s no need to be setting deadlines with version names.

In practice it means that Unity LTS are stable versions, normal version are betas, betas are alphas and alphas and pre-alphas ;/

I totally agree with you (the LTS will be the official from now on haha good one), this year.x model is awful (even the name is ugly). Still, it’s better two tech releases than three, so this is great, at least.

I hope one day Unity will announce the “Dead of the year.x versions” and “Unity 6” at the same time :) it would be awesome.

“Unity LTS are stable versions, normal version are betas, betas are alphas and alphas and pre-alphas” Couldn’t have said it better myself, you summed it up.

Comments are closed.