Search Unity

Unity 2020.1 でのパッケージマネージャーのアップデート

, 6月 24, 2020

ますます多くの機能がパッケージの形で提供されるようになる中で、各機能の開発の進行度にばらつきがあることが原因で、プロジェクトに適したツールを選択することが困難になるケースが出てきています。Unity 2020.1 でのパッケージマネージャー自体のアップデート、およびパッケージマネージャーでのパッケージリスト表示方法のアップデートにより、プロジェクトでプレビュー版パッケージを使用した場合の影響を考慮しやすくなり、より先のことまで見通しの立つ開発体験を実現できるようになります。

プレビュー版パッケージの使用にはリスクがあります。例えば、API や機能の変更により、本番環境で新しいツールを引き続き使用することができなくなる可能性があります。一方で、Unity の最先端にいることを楽しむユーザーも多くいますし、リリース前の技術を試すことは、チームが将来のプロジェクトに必要なツールを準備したり、その技術によって得られる機会を見通したりする上で役立ちます。アーリーアダプターからのフィードバックは、私たちがすべての人にとってより良いツールを作るための助けにもなります。また Unity として、ユーザーがより多くの情報に基づいてプロジェクトに関する決定を下せるように、より明確な情報を提供できるように取り組んでいます。

プレビュー版パッケージを追加したい場合は、プロジェクト設定のチェックボックスを操作してプレビュー版パッケージを表示させる。

パッケージの目標

パッケージという仕組みは、最新の Unity ツールや機能をより簡単に利用できるようにするために取り組んでいる一連の対策の第 1 歩となるものです。Unity の目標は、製品の開発に採用しても安全と考えられるパッケージをより明確に示すこと、およびあるパッケージがいつ検証済みになるかの目安を示すことです。同時に、ユーザーが早期のテストやフィードバックのために実験的なパッケージにアクセスできるようにしたいと考えています。

パッケージマネージャーで検出可能なパッケージリストの再検討

全社的な取り組みとして、パッケージリストを再検討し、まだ正式版よりは実験的なパッケージに近いプレビュー版パッケージ、またはアクティブに開発が進んでいないプレビュー版パッケージを特定しました。Unity 2020.1 以降のバージョンでは、これらのカテゴリのプレビュー版パッケージはパッケージマネージャーに表示されません。しかし、これらのプレビュー版パッケージを既にインストールしている場合、プロジェクトから削除されることはありません。引き続き、それらのパッケージを使用できますし、アップデートがあった場合はそれを受け取ることも可能です。

私たちの意図は、開発チームが、そのパッケージがそのバージョンのリリースサイクル内で検証済みに移行できると確信した場合に、パッケージマネージャーにプレビュー版パッケージが表示されるようにするというものです。例えば、Unity 2020.1 でプレビュー版パッケージがパッケージマネージャーに表示されている場合、そのパッケージは Unity 2020 LTS のリリースまでに検証済みに移行させることを計画しているということです。当然のことながら、予定は変更される可能性がありますが、どのパッケージを表示するかをフィルタリングするための最初の指針として、こうしたやり方を選択しました。

開発の初期段階にあるパッケージや実験的と考えられるパッケージも、引き続き製品レジストリで利用可能なままにしておきます。これらのパッケージは、プロジェクトマニフェストを編集することで追加することができます。このカテゴリに入るパッケージの完全なリストは、このフォーラムの投稿で見ることができます。

Unity は、ユーザーにとってパッケージをよりわかりやすくする方法を引き続き模索しています。皆さんからのフィードバックをぜひお寄せください。プレビュー版パッケージに関するフィードバックを提供したい場合は、ベータ版テスターのニュースレターにサインアップしてください。テスト可能な新しいパッケージが準備できたら、そのパッケージがパッケージリストに表示されていない場合でも最新情報をお送りし、使い方や開発チームへフィードバックを送る方法の詳細をお知らせします。

Unity 2020.1 に関する詳細

今すぐ Unity 2020.1 を使ってみたい方は、Unity 2020.1 ベータ版の公開を知らせるブログ記事Unity 2020.1 ベータ版の概要を説明するウェビナーをご覧いただき、ダウンロード方法や、搭載予定の機能や改善点の詳細をご確認ください。

今後登場予定のテクノロジーに関する情報を得たい、あるいは Unity の開発者から最新情報を得たいという方は、ベータ版ニュースレターへのサインアップや、ベータ版フォーラムへのご参加をご検討ください。

34 replies on “Unity 2020.1 でのパッケージマネージャーのアップデート”

This seems like a MASSIVE step backwards. Why not have the option to show “preview” packages and then also have one to show the “prototype” packages? And for the packages that are planned to have no further development, if that’s the case, why hasn’t this been communicated to us?

There’s many problems, all summed up in previous comments.
I would ask this same precise point: rename ‘preview’ to ‘prototype’.
Keeping the word ‘preview’ is just…insulting. At best.

The whole concept if “preview” packages is broken. In reality, users are forced to use latest “preview” versions not because of the reasons you listed, but because they contain fixes to critical bugs that make “verified” versions simply unusable.

Example: Addressables. I don’t know of any reason anyone would want to use “verified” version (which is now ancient) instead of the latest one.

The one feature that makes the horrible package manager worth it, you want to remove it…

Who is making these decisions….please reconsider

A couple of questions come to mind.

– Why make a new main entry in Project Settings that holds just a single toggle setting? You are crowding the menu. Perhaps a show/hide toggle belongs locally, close to the elements being hidden and shown. If the intension is to make the setting harder to find, so that fewer people use preview package, perhaps 1) rethink the UI instead, 2) adopt alpha-beta terminology, 2) stop promoting new packages widely before they are ready for a wide audience.
– Why are you asking users to edit manifest files manually again? Why not design UI that guide and warn? Perhaps packages that are not updated since X months could be marked as not under active development. Or perhaps let users rate and review them, just like Asset Store products.

Other hurdles with the Package manager.

– Why do users still have to spend time removing unnecessary packages every time they create a new empty project?
– Why does it take so long to remove packages, one at the time?
– Why haven’t you reached out to Asset Store developers, providing clear instructions on how to conform to the package manager file structure / layout? Tutorials are missing. The “Package Development” package is still in preview. The manual is helpful, but in practise, I am still confused. For example, how to ensure that packaged shader include files referenced by user shaders in the asset folder keep valid paths when switching from “In -Development mode” to production?

Otherwise, great work with the Package Manager. I look forward to making things that integrate well with it.

Alright, now I am completely confused by Unity.
As some others have already said, this is a huge step backwards. You have already LITERALLY put toggles in the Project Settings to prevent Preview Packages from showing up… And now you’re removing Preview Packages entirely? What happened to “we’re improving the packaging manager!”? It was literally on this year’s roadmap! And now… You do THIS? Preposterous.

Being a person who uses the cutting edge of Unity and supports it — this seems pretty dang wrong… But I know WHY you’re doing it. I just think your methods are pitiful, band-aid solutions that bite the developers who want the future of Unity as much as Unity does.

And as for the WHY… If you didn’t want people to be using Preview Packages that clearly were not ready for the wider Unity audience, can you please tell me why the heck you keep promoting DOTS and other in-preview technologies? I mean THAT’S the reason why people are adopting things too soon and then coming to the forums and complaining that the Preview-Packages are trash. It’s because you are promoting something that ISN’T READY to be put out into the world. And now you try to fix it with this “solution.” Ugh…

Unity — DO NOT DO THIS TO YOUR EARLY ADOPTERS.
It’s a bad decisions that you’re making on top of a LOT of bad decisions that led up to this issue. If you don’t want people using Preview Packages (Which really should be called “Prototype” rather than “Preview”, or “Alpha”), then you should put explicit warnings when attempting to use them that the technology is an unfinished, possibly broken, prototype, that should only be used at your own risk. END OF STORY.

And don’t get me started how you literally made a SURVEY asking people what kind of improvements they want for the Package Manager and then you immediately turn around and do THIS.
That one’s just beyond me.

There is actually a difference between the Preview packages that are still discoverable in the editor (with the preview setting toggle) and the ones that were removed from the discovery list. The preview packages that are shown are the ones that are on their way to become verified (in the year or so). The others were experimental packages or packages that are used internally by other packages and not meant to be used by all for production purposes.

The goal here is to make it clear to our users what is production-ready or not.

Yes, but in doing so you have slapped the entire DOTS community (and everyone who uses Unity’s cutting-edge) in the face.
Isn’t that fantastic?
Fantastic.

Mmmmm. I suggest not eliminating said packages that will now need to be manually added via the manifest. That creates MORE HASSLE for developers. It would be simpler to create clearly labeled categories to list these packages in the package manager. Between this and the licensing model for Project Mars, I’m becoming concerned with Unity’s recent decision making processes.

All the packages that were available will still be, with the only difference that they will need to be added manually. We are looking into ways to make it easier for experienced users to use these packages. For now, you can use the “Add package from git URL…” option and just type in the package name (e.g. com.unity.mathematics) and it will instantiate the latest available package from the production repository.

Thanks for your suggestion about the labeling.

This is a great move – thanks!

That said, the list of packages is currently slightly worrying – Entities, for example – including some things we thought were going to be ready for 2020 LTS. Hopefully the statuses of some of those will change over time.

Please, add the possibility to install 3rd-party packages from git with respect to their dependencies. Like npm. There are things like openupm.com to overcome this limitation, but it requires the preinstallation of additional software(custom git cmd line). For me, the developer, it might be ok. But I work with designers and I need them to be able to easily download and run my project, without additional and complicated steps.

Please! Let Unity community build a powerful network of tools!

Please actually explain which packages are no longer actively developed, as if you yourselves admit that is happening why allow users to continue to rely on them if they DO NOT KNOW OTHERWISE???

Maybe you could finish Unity Recorder or Terrain Tools? Seems like they are left in perpetual preview.

This is a huge step backwards in my opinion. Manually editing the manifest file was embarrassingly bad the first time around. Going back to that is inexcusable.

Make a preferences option for whether alpha packages should be visible or not. Default it to NO so it will take some manual effort to turn it on, and not have this visible for everyone. This would at least be doable for trying these features with my students.

thanks for your suggestions, you are welcome to follow up with the product managers on our forums

I totally understand the need to do this and I support this decision. No sarcasm. I don’t wanna see not-ready-to-use packages in the manager which confuses me and others working with me. Like AAA games need to be ready to play on release day without major bugs, Unity packages must be included in the Unity experience when they are “almost” ready.

“…or else not under active development”

Is there a list of packages that fit that criteria? Just so us developers don’t unwittingly hitch our cart to a dead horse.

Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, Please, make it possible to add/ remove multiple packages at the same time!

Due to the long wait and load after removing a package, it takes far too long to remove all the useless default Unity packages that are added to new projects.

That reminds me…is there a way to save a project as a template, other than manually copying a folder. I feel I should be able to create my project with my shosen packages, and then just itterate on them. I swear I’m rebuilding Unity to my satisfaction every other week.

This is the direction we are heading. As we are working on new templates, we will make it easier/possible for our users to do so as well.

That call the “Package/manifest.json” file in your root folder ;)

(I did a script in my facilitator that allows to remove several package at a time.
I need to improve it a bit to add directly links of the new one to add.)

How is the company that makes a game engine not using software release terms like alpha and beta? Expecting major changes in functionality as the package is bleeding edge? It’s an alpha release. Expecting generally stable performance with maybe a few minor tweaks before production release? It’s a beta release. Why does it need to be so complicated?

Most of the design decisions for Unity Package Manager were inspired by existing managers like npm. The naming of the version was up to the developer. With time, we realized Unity users wanted to know more, so we came up with tags for Preview and Verified packages. As we are moving forward, we are making small adjustments to this.

The package manager in its current state reminds me of Netscape in 1995 when you were about to click somewhere and all of a sudden – right when you click – something different pops up and you activate that.

Background loading is nice and all, but it should be blocking the package manager UI itself and be cancel-able.

Let me echo what Jes said in the first reply to this blog post. As developers, we often want to have easy access to early “Prototypes” knowing full well that they are bleeding edge. Rather than having to edit the project manifest, which is a cumbersome process and prone to error, allow developers to add Prototype packages like other Preview packages. Packages should be easy to add and remove. Manual editing of manifests gets in the way of effective developer workflows.

But let me add one more suggestion on top of this… Make the Development Build in the Project Build Settings automatically enabled if there are any Prototype packages in the Project.

All the packages that were available will still be with the only difference that they will need to be added manually. We are looking into ways to make it easier for experienced users to use these packages. For now, you can use the “Add package from git URL…” option and just type in the package name (e.g. com.unity.mathematics) and it will instantiate the latest available package from the production repository.

Please follow the forum thread here for more details:
https://forum.unity.com/threads/visibility-changes-for-preview-packages-in-2020-1.910880/

Cool for start thanks :)

Please consider option to just get rid of preview label and replace it with prototype label for packages that will not ship any time soon and checkbox in package manager to se them instead of separate registry.
for packages that will ship in current major unity version consider to use worldwide used stage labels (alpha, beta, rc)

Yes, “prototype” is more appropriate. I think they use this branding marketing technic to attract more people to use and test the product in the beta stage. But that user that was thinking it was a preview in the final stage is disappointed and complain.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です