Search Unity

Unity の新しいリリースプラン:TECH ストリームと長期サポート(LTS)ストリームの導入

, 4月 9, 2018

GDC にて、私たちは Unity の新しいリリースプランを発表しました。新しいリリースプランは TECH ストリームと長期サポートストリーム(LTS)の 2 つのストリームで構成されます。TECH ストリームでは毎年 3 回のメジャーリリースがあり、各メジャーリリースには新機能が盛り込まれます。その年のうち最後にリリースされた TECH ストリームでのリリースがその年の LTS ストリームでの最初のリリースとなり、翌年へと持ち越されます。このブログ記事では、新しいリリースサイクルの思想を説明し、続けてよくある質問への回答を提示します。

TECH ストリームと LTS ストリームの導入により、それぞれのリリースを 1 年間サポートする現在の体制から大きく転換することになります。新しいリリースサイクルでは:

  • TECH ストリームでの、あるメジャーリリースのサポートは、そのメジャーリリースの次のバージョンがリリースされると同時に終了します。
  • LTS ストリームでのリリースは 2 年間サポートされます。

それぞれのリリースへの Unity のアプローチは上記に述べた以外の点でも変化します:

リリース回数が 4 回から 3 回に変更:これまでの年 4 回リリースを行う体制から、年に 3 回 TECH ストリームでのリリースを行う体制に移行します。

その年の最初のリリースは春に行う:TECH ストリームは毎年春に開始するものとします。今年のリリースバージョンは 2018.1 から始まります。春にリリースを行った後は、夏と秋にそれぞれリリースを行います。

バグフィックスの頻度:TECH ストリームでは毎週バグフィックスをリリースします。これに対して、LTS ストリームでは隔週でバグフィックスをリリースします。

パッチからアップデートに変更:毎週リリースされるパッチには「.p#」サフィックスが付与されなくなります。これはパッチに対するテストを改善して、リリースするものはパッチではなくすべてのユーザーにお使いいただけるアップデートになると判断したためです。

新しいストリームの運用

最初の LTS ストリームでのリリースは 2017.4 となります。これは 2017.3 に最新のアップデートを適用したリリースです。「2017.3」から「2017.4」へのバージョン番号の変更は、新しい LTS サイクルが開始したことを示します。つまり、「xxxx.1」「xxxx.2」「xxxx.3」というバージョン番号がつけられたリリースは TECH ストリームでのリリース、「xxxx.4」というバージョン番号がつけられたリリースは LTS ストリームでのリリースであることを示しています。

TECH ストリーム、LTS ストリームの両方で行われる定期アップデートでは、連続したバージョン番号がつけられます。たとえば、2017.4.0 の次は 2017.4.1、2017.4.2、2017.4.3、…のように、アップデートごとにバージョン番号が上がっていきます。

下の図は 2 つのストリームがどのように運用されるかを示したものです。青いボックスは TECH ストリームを、緑のボックスは LTS ストリームの開始を示します。

新しい TECH ストリームと LTS ストリーム

よくある質問

なぜ Unity は現在の体制を変更するのですか?

リリースを TECH ストリームと LTS ストリームとに分けることで、顧客のニーズに沿って、私たちの製品の価値を最大化できると考えたからです。開発サイクルのどのフェーズにいるかにより、新しい機能(TECH ストリームのリリース)を試したいか、新しい機能の追加は必要とせず、いま使っているバージョンのバグフィックス(LTS ストリームのリリース)だけ受け取りたいかが決まると思われますが、これらのニーズに各々対応できるメリットもあります。

開発の初期段階や途中段階にあるチームや、最新機能について調査されている方に向けては、TECH ストリームでのリリースという形で新しい機能をすべて盛り込んだ最新バージョンの Unity をリリースします。開発の終盤にあるチームや、すでにリリースされたゲームを運用されているチームに向けては、LTS ストリームからバグフィックスのみを追加したバージョンをリリースします。

この変更の背景にある最も重要な思想はどのようなものでしょうか?

サポート対象とするストリームを 2 つに絞り、LTS ストリームからのリリースではバグフィックス以外行わないよう厳密に管理することで、顧客へのサポートをより効果的で、より効率のよいものにすることに注力したいという考えがあります。TECH ストリームで次々に出てくる新技術にフォーカスし、LTS ストリームで成熟した機能を搭載したバージョンへの長期サポートを提供すれば、ユーザーからの多様なニーズの大半に応えられると見込んでいます。ただ、ユーザーからのフィードバックは引き続き受け取りますし、この体制の運用を行っていく中でプロセスは継続的に改善していきます。

TECH ストリームと LTS ストリームとのつながりは何でしょうか?

新しい TECH ストリームが始まったとき(たとえば、バージョン 2019.1 がリリースされたとき)、その前のバージョン(この例では 2018.3)には 2018.4 というバージョン番号がつけられ、LTS ストリームからのリリースとなります。

TECH ストリームからのリリースに対しては、どの程度の頻度で更新があるでしょうか?

TECH ストリームでは毎週更新がリリースされます。TECH ストリームの開発リソースの大半が TECH リリースを可能な限り早く安定させ、改善するために注入されます。

LTS ストリームについて、リリース後に出た要件に応じた開発や機能の統合はどのように進められますか?

LTS ストリームを 2 年間サポートすることの意義は、顧客が使いたいバージョンを使い続けられるようにすることです。LTS リリースの後に生じた、サポートを必要とする変更はケースバイケースで追加対応を行います。

なぜ「< リリース年を示す4桁の数字>.4」というバージョン番号を使ったのですか?

2 年間のサポート期間の始点をはっきり示したかったからです。また、新しい LTS ストリームを新しい TECH ストリームとほぼ同時に始めるようにしたかったという面もあります。

LTS とは何の略ですか?

LTS は「Long-Term Support(長期サポート)」の略です。

LTS ストリームのサポート期間はいつまででしょうか?

LTS ストリームからのリリースは、それぞれ、リリースがアナウンスされた時点から 2 年間サポートされます。

LTS ストリームの対象ユーザーはどのようなユーザーでしょうか?

LTS ストリームは安定したバージョンでゲームやコンテンツの開発、リリースを引き続き行いたいというユーザーに向いています。

TECH ストリームの対象ユーザーはどのようなユーザーでしょうか?

TECH ストリームは最新機能を試したり、最新の Unity が提供する機能にキャッチアップしたいユーザーに向いています。

LTS ストリームで対処される主な問題は何でしょうか?

LTS となったバージョンには、新機能や API の変更または改善などは盛り込まれません。LTS ストリームのアップデートでは、クラッシュ、リグレッション修正、コミュニティの広範囲にわたって影響する問題、コンソール機向けの SDK/XDK、多数のユーザーがゲームのリリースを行えなくなる可能性がある大きな変更などに対処します。

TECH ストリーム、LTS ストリームの両方にアップデートはありますか?

はい。どちらのストリームにもアップデートがあります。

TECH ストリームでは毎週アップデートがリリースされます。ただし、TECH ストリームからリリースされたあるバージョンへのアップデートは、次のバージョンがリリースされると終了します。たとえば、2018.2 がリリースされると、2018.1 に毎週行われていたアップデートは終了します。また、2018.3 がリリースされたら、2018.2 へのサポートは終了します。

LTS ストリームからリリースされたバージョンに対しては、最短で 2 週間に一度、アップデートがリリースされます。アップデートは 2 年間続けられ、バージョン番号は、たとえばバージョン 2018.4.0 から始まる LTS ストリームでのアップデートの場合は、2018.4.1、2018.4.2、…、2018.4.24 のようになります。

TECH ストリーム、LTS ストリームのそれぞれからのリリースにおけるアップデートにつくバージョン番号に変更はあるでしょうか?

TECH ストリームと LTS ストリームの両方で、すべてのアップデートには「.f」サフィックスが付与されます。これは両方のストリームからリリースされるバージョンが、パッチではなく完全にテストされた、すべてのユーザーにお使いいただけるものであることを示します。

各ストリームでリリースされるものをパッチとは呼ばずアップデートと呼ぶのはなぜですか?

私たちはこれまでパッチに付与してきた「.p」サフィックスを「.f」サフィックスに付け替えます。これは各ストリームから定期的にリリースされるものがパッチに対するテストからより拡張したテストを経てリリースされているためです。アップデートの作業にあたっている Sustained Engineering QA チームでは少し前まで行っていた、パッチリリースに入れるバグフィックスの検証に追加したテストを実施するようになりました。この拡張されたテスト工程(リリース受け入れ試験と呼ばれるもの)は、さまざまな領域をまたいで行われる手動テストのホスト全体を使って実施されています。このため、パッチリリースと公開リリースにまとめる作業の両方を行う必要がなくなりました。

5.6、2017.1 などの古いバージョンはどうなるのでしょうか?

これまでに述べた通り、2017.3 が 2017.4 となり、同時に 2017 バージョンの LTS の初期バージョンとなります。これまでに告知している通り、古いバージョンには「.p」サフィックスがつけられたパッチリリースによるサポートが、それぞれのバージョンがリリースされた時点から 1 年間にわたり行われます。

35 コメント

コメントの配信登録

コメント受付を終了しました。

  1. 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.

  2. Marcos Elias

    4月 22, 2018 10:15 am

    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.

  3. 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.

    1. Never mind, I found download links here: https://unity3d.com/unity/qa/lts-releases
      I was directed to that page from this forum post: https://forum.unity.com/threads/unity-2017-4-lts-is-now-available.526260/

  4. Paul thomson

    4月 16, 2018 11:57 pm

    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. https://appletechsupportnumber.net/ iPhone support is also updating and enhancing the user experience.

  5. Please, update Particle System Improvements in 2017.4.2 which were introduced in 2018.1.
    https://docs.google.com/document/d/1JbvE-O_mx7WRmub4u1x-nDQ6HmFDzkDQ5lbbrVkI93E/edit

    1. Richard Fine

      4月 13, 2018 11:12 pm

      Sorry, but these constitute new features, so we will not be accepting them into 2017.4.

  6. “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.

    1. Agreed, totally confusing. +1 for 2018.1f2

  7. What about the Beta Program. Should I assume that this is also replaced by the TECH stream?

    1. Richard Fine

      4月 11, 2018 10:12 am

      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.

  8. 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.

  9. Aaron Fothergill

    4月 10, 2018 11:05 pm

    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.

  10. 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)

  11. Ravindra Singh

    4月 10, 2018 5:08 pm

    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

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

  13. Chris Buguet

    4月 10, 2018 9:39 am

    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.

    1. SDKs will be updated for LTS

  14. Daniel Nora

    4月 9, 2018 8:27 pm

    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.

    1. Richard Fine

      4月 9, 2018 10:20 pm

      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.

      1. Daniel Nora

        4月 10, 2018 3:22 pm

        Cool!

  15. 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.

  16. Guney Ozsan

    4月 9, 2018 4:26 pm

    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.

    1. 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…

    2. Richard Fine

      4月 9, 2018 4:58 pm

      > 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.

      1. Guney Ozsan

        4月 9, 2018 11:00 pm

        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.

  17. Wish 2017.4 (LTS) had support for Tizen

  18. Wish 2014.4 (LTS) had support for Tizen

  19. Looks great to me! Thx for your work and effort!

  20. Alan Mattano

    4月 9, 2018 2:57 pm

    Do Unity 5 include a TECH releases?

    1. Richard Fine

      4月 9, 2018 2:59 pm

      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.

      1. 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?

        1. Richard Fine

          4月 15, 2018 11:36 am

          Yep, 5.6.6 will be a rollup, and the final public release in the 5.6 line.

  21. Ippokratis Bournellis

    4月 9, 2018 2:09 pm

    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.