Search Unity

New plans for Unity releases: Introducing the TECH and Long-Term Support (LTS) streams

, abril 9, 2018

At GDC, we announced our new plans for Unity releases, which include what will be known as the TECH stream and the Long-Term Support stream (LTS). The TECH stream will consist of three major releases a year with new features and functionality. The LTS stream will be the last TECH stream release of each year and will roll over to the following year. This blog post explains the idea behind the new release system followed by answers to Frequently Asked Questions.

The TECH & LTS streams represent a major shift from the current approach of supporting each of the releases for a year. From now on:

  • Support for each respective TECH release will end when the following one goes live.
  • LTS releases will be supported for two years.

Other aspects of our approach to releases will also change:

From four to three releases: Instead of four feature releases, we are going to ship three TECH stream releases per year.

First release in spring: Each year, a TECH stream will begin in the spring, this year starting with 2018.1. This will be followed by summer and fall releases.

Frequency of bug fixes: Whereas the TECH stream will receive a weekly release with bug fixes, the LTS stream will receive regular bug fixes every other week.

From patches to updates: We are  dropping the .p# suffix for our weekly patches because, due to our improved testing of these releases, we believe they will be suitable for everyone.

How the new streams will work in practice

The first LTS release will be 2017.4, which is simply the latest 2017.3 updated release. The change in version number signifies that it is the beginning of the new LTS cycle. So, xxxx.1, .xxxx.2 & xxxx.3 are TECH releases and xxxx.4 is the LTS release.

The regular updates on both TECH and LTS streams will have continuous version numbering. For example, 2017.4.0 will be followed by 2017.4.1, 2017.4.2, 2017.4.3, and so on.

The chart below shows an example of how the streams will work, with the blue boxes representing the TECH streams and the green boxes representing the beginning of the LTS streams.

The new TECH and LTS streams


Why is Unity changing the current approach?

Splitting releases into the TECH and LTS streams will enable us to offer you the maximum value according to your needs. Depending on where you are in your development cycle, you may want either to try out new features (TECH release) or only to get bug fixes in the version you are using for a longer period without adding new features (LTS).

For those of you starting or in the middle of production, or just looking for the latest features, we offer the latest version of Unity with all the new features in the form of the TECH stream.  For those of you who are nearing the end of production or are operating a live game, we have the LTS stream in which only bug fixes are added.

What are the main ideas behind these changes?

With only two streams to support and with LTS strictly controlled for bug fixes, we can focus on supporting you more effectively and efficiently. By supplying one stream focusing on new technology and another providing long-term support for a version with matured features, we expect to cover the majority of different users’ needs. However, we will continue to listen to your feedback and improve the process as we go.

What is the connection between the TECH and LTS streams?

When a new TECH stream goes live (for example version 2019.1), the previous version (in this example, 2018.3) will become an LTS with a new version number, 2018.4.

How frequently do the releases from a TECH stream get updated?

TECH streams will be updated with weekly releases. Most of the development efforts will be focused on stabilizing and improving the TECH releases as soon as possible.

How will future requirements/integrations be dealt with?

The objective is to support the LTS stream for two full years for customers who choose to stay on it. Any future changes requiring support will be added on a case-by-case basis.

Why did you bump the version number to YEAR.4?

We wanted to have a clear point at which the two-year support schedule begins. Also, we wanted to begin a new LTS stream at around the same time the new TECH stream begins.

What does LTS stand for?

LTS stands for Long-Term Support.

How long will an LTS stream be supported?

Each LTS release will be supported for two full years from the time it is announced.

Who is the LTS stream intended for?

The LTS stream is for users who wish to continue to develop and ship their games/content and stay on a stable version for an extended period.

Who is the TECH stream intended for?

The TECH stream is for anyone who wants to use the latest features and those who want to be up-to-date with the latest Unity is offering.

What are the main issues that an LTS stream will address?

The LTS version will not have any new features, API changes or improvements. It will address crashes, regressions, and issues that affect the wider community, console SDK/XDK, or any major changes that would prevent a large section of users from shipping their game.

Will there be updates for both the TECH and LTS streams?


We will continue to offer weekly updates for the TECH stream. However the updates for the current TECH stream will stop when the next one is released. For example, when 2018.2 is released, weekly updates for 2018.1 will stop, and when 2018.3 goes live, support for 2018.2 will end. 

The LTS updates will be less frequent with one every other week. The updates will continue for two years with the version numbers going as: YEAR.4.1, YEAR.4.2, …, YEAR.4.24, for example.

Will there be any version number changes to updates for the TECH and LTS streams?

All updates for both TECH and LTS streams will have .f suffixes as they are not patches but fully tested updates recommended for all.

Why do you call them updates and not patches ?

The .p suffix used for patches has been replaced by the .f suffix because these regular updates are released with extended testing. This is due to the change in our release-testing process. The dedicated Sustained Engineering QA team has started doing extended tests in addition to verifying each of the bug fixes in patch releases some time ago. This extended testing, known as Release Acceptance Testing, is performed using a whole host of manual tests done across various areas. So, there is no need to do both patches and wrap-up of public releases any longer.

What happens to the legacy versions, 5.6, 2017.1 & 2017.2 ?

As mentioned, 2017.3 has become 2017.4 marking the beginning of 2017-LTS. As promised, all legacy versions will be supported with patches, with .p suffixes for a year from their releases. 

35 replies on “New plans for Unity releases: Introducing the TECH and Long-Term Support (LTS) streams”

I like this idea quite a bit. Most larger studios will want stability once their games gets closer and closer to release. They can plan their development and stabilise earlier enough to land on a .4 build. Then they can still ride the wave for a period of time with the new projects also and sandbox projects.

No one likes the idea of of a simple bug fix being rolled up into a release that has architectural changes.

Is there any chance that we won’t need to reimport assets at each update? For example between patches or little updates inside the same main version…

Updating should require asset reimport only if something has been changed about the assets settings in the new release. Unity could have a special flag to check this. For example, upgrading from 2018.1f1 to 2018.1f2 should not require asset reimport if you devs know that nothing has been changed in asset settings with the new update… If a new update brings something that would really require asset reimport, then it could make it at the first time when opening the project with the new version.

When I have to update my project I spend almost one or two entire days, it’s huge and I maintain the PC and Android in two separate directories/projects. This is very frustrating for patches/frequent updates.

Umm… the download link provided seems broken. Every page I look at, even the download archive and other places, list 2017.3 as the most recent release. Am I missing something or do the download pages need updating? Thanks.

This is great as there is a chance of enhancing the user experience and to modify according to the user. upgradation in the technology always helps and it will be helpful in the near future. iPhone support is also updating and enhancing the user experience.

“The .p suffix used for patches has been replaced by the .f suffix because these regular updates are released with extended testing”.
So we will have 2018.1.2f1 or just 2018.1f2? Please do the second, the first is quite confusing, because for example 2018.1.2f1 can be confused with 2018.2.1f1.

Nope, the beta programme is unaffected by this. You’ll continue to see 2-3 months of beta builds in the run up to each major TECH stream release.

LTS stands for Long-Term Support, but what does TECH stand for? Please tell me it’s an acronym because capitalizing it for no apparent reason is annoying.

Can you make it so that LTS releases don’t block the Append option when building to Xcode for instance? We do a lot of post build stuff that gets broken if we have to do a clean Xcode build (and build post processing can’t handle) so it’s a major pain and usually a lost day if we have to update to a new Unity p or f build because it fixes a Critical Unity Bug at the moment and rebuild the whole Xcode project. If the LTS versions are essentially just fixes then it shouldn’t need to reset the Xcode project every time.

Such good news! … you guys had a support nightmare with how many versions you were back-patching.

Hopefully this lets you provide better support for the more nuanced platform-specific bugs/regressions that sometimes crop up. (e.g. UnityWebRequest on iOS)

Outstanding news!

Just one observation… could you please fix the download link as it leads to 2017.3. I had to dig a bit to find 2017.4

Cool i suppose. Any chance to get incremental updates/patcher so there would be no need to redownload whole Unity with every update? :/

Excellent news!

TECH stream will be very interesting for XR developers. SDKs and hardware are still changing very quickly, and this will be the best way to keep state of the art apps/games.

This is really great news!

There is however one little thing that I’m not 100% comfortable with, which is the promise to not make API changes in the LTS releases. In most cases this would be perfectly fine, but every now and then it’s necessary to add a new API in order to make a game compatible with the newest devices. For example, last year’s release of the iPhone X made it necessary to add the Screen.safeArea API. What I’m wondering is if these simple, but critical APIs will still make it to LTS, otherwise those releases may become effectively useless for a large percentage of developers.

Yes, what we’re mostly forbidding is changing or removing existing APIs. Adding is lower-risk, and as you say, sometimes necessary to support things like new devices.

Thank you so much for these new plans for Unity releases. I really applaud you for them. I felt there was a quickly growing demand for stable Unity versions.

This sounds very promising. Thanks for the improvements and clarification. One thing I’m curious is (or what I understand is) since each TECH release stops support for previous one, if we start making a game using 2018.2 then we need to update until we reach 2018.4 to reach LTS, no matter what, even if there are game breaking API changes or features introduced. Then we can stop stable at 2018.4 for the next 2 years and keep receiving fixes…etc. So is it better to make the game using 2017.4 and wait for 2018.4, or 2019.4 for updating unity versions so that we work on breaking changes once or twice a year? That would be awesome if you can clarify this point.

Yes this is the only concern. If .3 adds new features and a load of new bugs but 1 important bug needs fixing in .2 then you could be in trouble. Still there is no perfect solution…

> if we start making a game using 2018.2 then we need to update until we reach 2018.4 to reach LTS, no matter what, even if there are game breaking API changes or features introduced. Then we can stop stable at 2018.4 for the next 2 years and keep receiving fixes…etc.

That’s correct. We are of course going to continue to do what we can to avoid doing things in the TECH stream that block you from upgrading between releases, but we’re balancing it against the continued need to clean things up and slot in new features. On the LTS stream, we’re 100% focused on stability and making sure that you can get the fixes you need, which means making sure that you can take a new LTS release without problems.

> So is it better to make the game using 2017.4 and wait for 2018.4, or 2019.4 for updating unity versions so that we work on breaking changes once or twice a year?

That really depends on your project and on how much risk you’re willing to take on. Certainly we expect some customers will only use the LTS releases, and jump LTS-to-LTS when it suits them – particularly for a project which is a later phase of its lifecycle. Meanwhile, other projects are perhaps more comfortable riding the TECH stream for a while, getting all the cutting-edge features and improvements, in exchange for potentially slightly more frequent upgrade pain.

To be totally clear: it’s not our intention that the TECH stream should be ‘unstable.’ We absolutely still intend for our .1, .2 and .3 releases to be production-quality, and making this change to our release cycle is going to free up resources we can use to further help ensure that happens.

Thanks. Richard. I have no doubt of the stability of TECH releases. I wanted to understand which upgrade strategy is better for different kind of projects. That was very helpful.

No, we’re not doing any new development on Unity 5. It doesn’t have LTS either – 5.6’s year of patches is almost concluded.

Is there going to be a final .f release that rolls all of Unity 5.6’s .p releases together? Or will we just have to use the final .p release?

Excellent choices.
Also, at some point, when the new per module update system that is introduced in v2018 matures, it will significantly improve the user experience on trying the experimental features. Very nice.

Comments are closed.