Package Manager updates in 2020.1 beta

Unity Engine
,
1

As the bulk of Unity’s functionality becomes modular and more features in different stages of development move into packages, choosing the right tools for your project can be challenging. Updates to the Package Manager in Unity 2020.1 beta 8 aim to make it easier for you to consider the impact of using preview packages in your project.

How to access all packages in 2020.1

Using preview packages has its risks. For example, API or functionality changes could disrupt the continuous usage of the tool in a production environment. Nevertheless, for those of you trying to stay on the bleeding edge of Unity technology, trying preview projects can help you to prepare the tooling necessary for future projects and anticipate opportunities. At the same time, your feedback helps us to make better tools for everyone.

Currently, the Show preview packages setting in the Package Manager is a preference that applies across all of your Unity projects and versions. This means that most users are only informed once about the implications of using preview technology. In 2020.1 beta, we changed this to a project-based option in the Project Settings.

Design updates
More prominent preview package labeling and a warning section in the Package Manager UI will remind you to be cautious when updating or installing packages in development. Additionally, a new Preview Package menu will be displayed in the Editor toolbar while you work on the project.

These new menu items can be dismissed or they can show you which preview packages are installed, and where you can find the description and changelog for these packages.

Additionally, we have added new improvements like a new UI iconography, improved layout, and better distinctions between Currently installed packages and the Update available information.

Plans for packages
This is the first step in a series of measures that we are working on to help make it easier for you to explore the latest Unity tools and features. Our goal is to make sure that all new packages that users can see in their Package Manager are either close to being ready for verification or already verified to work with that version of the Unity Editor.

Preview packages that aren’t yet close to the verification stage won’t be listed in the Package Manager. However, if you’ve already installed these preview packages, they won’t be removed – you can continue to use them, with the understanding that they are experimental.

You can discuss the changes to the Package Manager in this forum post. We would love to hear what you think of the latest Unity UX changes – this helps us to know what to improve next.

5805625--613969--image1.jpg
5805625--613969--image1.jpg1918×926 224 KB

5805625--613972--image2.jpg
5805625--613972--image2.jpg1918×926 223 KB

5805625--613975--image3.jpg
5805625--613975--image3.jpg1918×926 251 KB

5805625--613981--Unity-2020.1-Packman-Forum.jpg
5805625--613981--Unity-2020.1-Packman-Forum.jpg1200×728 118 KB

6 Likes
2

It is looks like very small step forward and it is good thanks :slight_smile:

One thing that looks bad is package that consume 2 lines instead of single line
Another is absence of groups
Third is another package statuses Preview is good but what is preview? Is it Alpha or is it Prototype, when package will be in Alpha, Beta. RC and finally release state?

Big scroll say that this UI somewhat bad and it is hard to find something in it. Group by category like 2D… may help.

For now we actually dont see any bug fix(hot fix) for package.
If package has stable version that is buggy, then UT ship new version with fixes but that new version is in preview and many versions with fixes after it in preview too.

So it looks like we very strongly pushed to use preview versions because Verified version is buggy and these bugs never fixed in stable verified version, Only in new previews. Good sample of this is Addressables package. Verified version is 1.1.10 but it is very buggy and actually I dont advise to use it in prodution. We end up on version 5.1 that way more stable but it in preview.

I propose you to create standard for package versioning that will push package devs to explicitly state status of package, updates, fixes and new versions.

e.g. you have semantic versioning major.minor.bugfix

use major version 0 [0.5.1] to indicate that package in prototype stage and can be dropped or redone in another way
use major version >= 1 [1.0.1 a] to indicate that package in a way to ship that major version and never change major version until dropping support for package.

use minor version to indicate new feature release for version
use bugfix version to indicate that it is just new bugfixes inside

use postfix to indicate state of release:
a - alpha - features somewhat work and will not be changed but very buggy. no documentation
b - beta - features mostly stable but have some bugs inside. most docs is ready
rc - release candidate - features and docs considered final and go through final testing stages
r - final release - stable product

In my opinion Stable version like [1.1.10 r] must become stable [1.1.11 r] after bug fixes. or in special cases can be shipped as rc [1.1.11 rc] just to indicate that additional testing needded and then become release [1.1.11 r] when tests actually passed.

New features can start from alpha stage like [1.2.0 a] to indicate new feature set and status of completeness, then [1.2.0 b] [1.2.0 rc] and finally [1.2.0 r]. May be allow to not release version and create new one like
[1.2.0 a] → [1.3.4 a] → [1.4.1 b] → [1.5.8 a] → [1.5.12 b] → [1.5.18 rc] → [1.5.20 r]

Major version must be changed only in package want do drop support for some LTS Unity version or just create absolutely new version of package with new basement. So there is moment when devs support few package version in time bugfixing and may be adding new features to version 1 while actively developing version 2.

7 Likes
3

They are not the changes I was waiting for, but thanks for working on refining it.

Each line item in the package manager takes up double the space now.

I wrote my first impressions here:

Package manager 2020.20a9

I will repeat some of those points here to keep them all in this feedback list

My first priority when using package manager is importing assets from the asset store.

Things I need for that to work smooth:

  • Load the whole list and keep it in memory.
  • Keep the old line spacing height. ( I can see double the amount of assets at one time. )
  • Make search more snappy ( search from memory not from the server )
  • Let me decide in settings if I want pagination or not
  • Let me add labels inside the package manager so I can organise by label.

The preview package in use warning is not really helping me import assets faster, it’s just telling me what I already know.

Thanks for the updates!

6 Likes
4

I agree with the sentiments above. I expect the current list of pacakges to double over the next couple of years as unity brings out more packages and replaces old ones with new ones (the asset bundle browser package is a good example) and that’s not even including scoped registry packages and embedded packages teams will use for a project.

I’ve written several packages myself and I’ve noticed that there’s several extra fields in the package.json schema that even existing unity packages are using like category but they’re not taken advantage of when it comes to searching or filtering packages in the window, making it harder to find what you’re looking for.

All in all, these changes are very much welcome but we still have a ways to go!

4 Likes
5

@LeonhardP , the preview thing is applied to all packages (included custom package) using “preview” as the pre-release identifier?

1 Like
6

The list of packages is now harder to look at because each line is no longer just the package name

6 Likes
7

^ This

8

Also echoing @Lars-Steenhoff . Thanks but this is not a solution to any of the problems your users are experiencing on a daily basis. And it actually creates or aggravates existing issues.

Are there any plans to address the feedback your users have been attempting to provide to you @LeonhardP ? The many ongoing issues with the PM that affect “My assets”? Any of the search issues? Labelling issues? Extensive issues experienced by those with many assets? (10 minutes and 40 seconds elapse between the time I click on sort by Update and when the UI updates itself to show me the new versions). Or UX horrors like the sort filter? Or… god forbid… the ability to know which assets users have imported in their project and what version it was that was imported?

3 Likes
9

@LeonhardP …

  • Text Mesh Pro and Terrain Tools packages are in Preview and hence give your users the big yellow warning in the package list (and also at the top of the editor, in case your users are not very bright). These packages are both v3.x.x and yet have always been in preview, even when going up major versions. What does that tell us?

  • when the big green Verified label appears next to a package, does that mean “verified for the version of Unity I have open” or does it actually mean it’s “verified for a version of Unity I may or may not be using”?

2 Likes
10

Please add an option to remove this button permanently. I guess it’s not enough that the Titlebar shows in all caps “PREVIEW PACKAGES IN USE”? Having to hide it every time I restart Unity is getting annoying and it’s pretty distracting to leave up.

3 Likes
11

Here is a bit of feedback regarding the new “Preview Packages in Use” button…

5860492--622948--upload_2020-5-17_8-48-47.png

I would like to understand the reason behind adding this button, can you explain that?

It seems the only new information, that wasn’t available before, is the new “Why am I seeing this?” link, which opens:

  1. Why do you ask to not use preview packages? Is this causing too much QA cases?

  2. If you want people to understand the implications of preview packages, I’m sure this button is not helping. You should add the preview disclaimer to every preview package inside the package manager window instead. And you actually did this, so you already believe the button is useless too.

5860492--622963--upload_2020-5-17_9-3-55.png
5860492--622963--upload_2020-5-17_9-3-55.png802×440 43.6 KB

  1. If you want people to read the preview disclaimer, you should probably change it to a warning and move it above the description.

  2. Yellow text on bright background is uncomfortable to read, but maybe that’s on purpose.

8 Likes
12

Hi everyone,

Thank you for the feedback.

The team is in the process of reverting the UX change to package lists so that it remains on one line.
The other request related to the Asset Store “My Asset’s” (pagination, labels) are also already in our backlog.

@transat The team has done extensive performance testing with many (thousands) of Asset Store assets. If you can share more details on you current problems (which release of Unity, how many Assets, log files etc…) we can investigate further; perhaps best to log a defect so we can track this officially please. Unfortunately, the .unitypackage format from the Asset Store doesn’t allow us to track which Assets are installed in project like we can with the newer UPM format

Re: Verified. This means verified for the version of Unity you are using. A package version today is always verified against a specific Unity Editor release. (E.g. packageA-1.0.0 Verified for Unity 2019.3)

Thanks,
Daniel

.

2 Likes
13

Hi Daniel,

you mentioned:
“Unfortunately, the .unitypackage format from the Asset Store doesn’t allow us to track which Assets are installed in project like we can with the newer UPM format”

I have thought about this and in a given project I could solve this by using the labels as follows:

  • I will give all the assets imported into the project the label with the ( project name )
  • Now its much easier to narrow down any updates and keep track of them ( I could also label the version number)

Its good to hear the labels will be able to be assigned inside the editor

Thanks for reverting the line height

14

Some UX horrors are going on there…
Maybe you guys should start giving the design part to the UX/UI team, instead of leaving it to the programmers?

2 Likes
15

@Lars-Steenhoff i used to do that hack when it was still possible. It’s one step removed from using a pen and paper. I’d rather a proper fix, as I know you and thousands of other users would too.

Hi Daniel. Thanks for your reply. Some more questions for you! Some rhetorical , some genuine. :slight_smile:

  1. Is your UX team concerned that “update” for “In project” = “import” for “My Assets” (with “update” meaning something completely different there?)

  2. When I import an asset in My Assets, is it technically possible for the editor to include the package name and version number in the .meta files associated to that package? And if so, would it also be technically possible for the editor to read from the meta files to not only let me know which version of the package I have imported but also to let me “remove” the package (as is the case with Unity packages)?

  3. Why does the PM suddenly know if an asset store package is in my project straight after I’ve clicked on import? Because in that “Import Unity Package” pop up confirmation window, the PM tells me precisely which files will change at my end, which have been deleted (at your end but not mine - no option for that) and which are new. That’s especially weird if, as you say, “ the .unitypackage format from the Asset Store doesn’t allow us to track which Assets are installed in project”.

  4. When you did your tests with “thousands” of Assets Store assets, did those assets eat up all of your laptop’s hard drive space or did you do what many users do and follow the hack suggested by [mention|AZfySL1YMDog85Grz+gbkQ==]… seven years ago ? As a real-life user, I’ve symlinked my asset store download folder to an external hard drive. And were your assets downloaded onto your machine or kept in the cloud? Did you test on various machines, operating systems and network bandwidths? In other words, did your tests use such a real-life scenario? As an aside, it would be nice to simply give us the option of whether or not we want to clog up our hard drives.

  5. Is there anything at your end that would justify a difference in time between when the PM is able to sort packages by update time and when the PM is able to display the actual new version and “Update” link (which as mentioned above, many new users would assume means the same as the In Project “update”)? Because I can guarantee you that is what is happening to me. The wait is anywhere between a couple of minutes and 12 minutes. I’m using Unity 2020.1 and 2020.2 on OS X Catalina, with a recent MacBook Pro.

  6. If Unity packages are “verified” for the version of Unity I’m using, why is URP 7 showing up as verified in 2020.1 and 2020.2 then? Because according to the URP team, it’s intended for 2019.3… hence my confusion.

  7. Do you ever do User Acceptance Testing before a release? And if so, are the “users” the actual programmers, as per @Neonage ’s comment, or real-life users? And if you actually do any UAT, how many users figured out right away whether they should click on “Sort: Update date [up arrow]” or “Sort: Update date [down arrow]” when you presented them with the scenario “as a user I want to sort my assets with the most recently updated ones on top”? Amusingly, “update” in “update date” has a 3rd meaning and doesn’t refer to whether the package was imported in the project nor If it was updated in my asset-store folder; it refers to whether it was updated (or simply had its description updated) on Unity’s asset store server.

2 Likes
16

@willgoldstone This is not your area but would love answers to any of these questions.

17

Yes good points, I would prefer a working version control for my assets too, but while thats not happening yet, the labels will save my sanity.

18

In response to my previous feedback …

While you’re at the Package Manager to move the preview disclaimer above the package description, as I described in the post above, can you also get rid of the “More…” button?

If you move the preview disclaimer above the preview, you don’t have to be afraid anymore it would move out of sight and you can just display the entire description text again. This avoids one click to read the description.

5891678--628190--upload_2020-5-24_11-9-57.png
5891678--628190--upload_2020-5-24_11-9-57.png906×691 41.8 KB

1 Like
19

@transat

Thank you for the active feedback. I’ll provide some genuine answers to all of your questions :slight_smile:

I would also like to point out that the “My Assets” integration in Package Manager was primarily intended to replace the previous ‘chromium embedded’ Asset Store workflow and not address the limitations of the .unitypackage format itself.

  1. Yes it’s something we’re aware and conscious of. Unfortunately it’s a result of lumping two different formats (and two different backend systems) into the same UI window. Unity Package Manager (UPM) format currently handles downloads+ updates/installs as a single operation. Whereas the .unitypackage hosted on the Asset Store, separates the download/import as two steps and in this case can only update to the latest version (limitation of the Asset Store .unitypackage format today). There is plan to split the operations for UPM in the future as well

2 &3. Technically anything is technically possible :). The “Import Unity Package” dialogue is not related to the Package Manager. It’s related Editor asset import pipeline and is the same windows you see in the Editor when importing the .unitypackage directly from disk. Once that file is extracted and imported it basically just becomes like any other asset in your project and that is where we lose the connection to the package and it’s hosted source. UPM is designed to maintain a reference to package cache and registry source when installing it in your project (thanks in part to the enhanced metadata inside the package and system itself running the Editor and our backend ),. The .meta files inside the .unitypackage were not intended to represent metadata for the package but the individual assets is my understanding…

4 &5.
No we don’t test with the workaround you mentioned but we do test across the OS’s we support, various machines and network conditions (e.g. proxies/firewalss and such) . Multiple QA teams are involved throughout our release process for any new feature to help with increased coverage. If your Asset Store product update/download is taking longer than it would depend mostly on the size of the package in question and network latency to our servers. I honestly can’t say much more than that but this behaviour should be not different in 2020.1/.2 Vs. any older release; if you’re seeing a regression please log it as a bug and we can investigate your log files for more clues.

  1. Since 2020.1 and 2020.2 are in various stages of beta/alpha (depending on which build you testing) packages versions will land at various points throughout the pre-release cycle as we stabilize the product. For example using 2020.1 beta 8 I can see URP 8.0.x is the now verified versio.

  2. We do rely on the alpha/beta forum as place for getting feedback ahead of the actual release. And yes do conduct user testing with actual users Are you interested in participating in a future study?

Thank you again for all the feedback
Daniel

20

Took me forever to figure out that the “Show Preview Packages” option has been moved to that new “warning drop down.” Not sure what else to call that thing.

2 Likes