Why add the qualifier “that are actively looking for feedback”? Why not list all packages that are hidden in the package manager?
If you want to actively deprecate some then say so. You imply that there will be packages that are a) hidden from the store b) hidden from your off-app list. Surely that’s as close to deprecated as you can get!
The problem was caused by multiple definitions of the word “experimental”. Unity had hobby projects that had been mostly abandoned mixed together with packages that were part of a major strategic initiative.
However I think this is an overreaction and a way of avoiding clear communication about each package’s prospects and status.
On a certain level I’m already using package manager like this. I browse Github repos for interesting stuff and often the install instructions are just “add the Git url manually to your manifest” There’s already repos on the Unity account I use this way.
But what bothers me about this is the lack of clarity over why packages have been demoted in this way and what future plans there are for each one.
Have been following the DOTS forum has been a long time and I can confirm that the issue is not due the word “preview” neither due to the lack of clear communication. The issue is that a lot of people just see those packages in the package manager and downloads it right away without even reading the landing page of the documentation (which becomes the main issue of a lot of help requested in the forums, even though there are pinned posts too with the documentation link).
Well, even for packages not in the package manager (like the DOTS VS) I see people complaining about the instability, even though it is stated clearly as far from production-ready. So I agree with the idea of making those packages not accessible directly from the editor, but also would like another way to find those or at least get notified when a new package/new version is available to try.
This would have been a lot simpler if:
Ultimately doesnt matter, developers who want access to these can manually add them to a manifest but it still seems like a weird way of doing things.
Just admitting “these X packages are no longer developed BTW” would have been nice too, right now people still dont know what is what on that list.
I agree with Alpha, Beta and RC labels. Unity uses them in other areas already, so users should be able to understand and these are standard terminology in software development.
However, I would use “Experimental” rather than “Prototype”. Mostly because “Experimental” is used in several Unity areas already, but also because other engines use “Experimental”. So we all speak one language when we jump between engines.
I just noticed that some of the packages that listed as being hidden from the package manager are listed as verified packages in the 2020.1:
com.unity.assetbundlebrowser
com.unity.editorcoroutines
com.unity.mathematics
com.unity.multiplayer-hlapi – obsolete
com.unity.render-pipelines.lightweight – replaced with URP
com.unity.test-framework
com.unity.xr.arcore
com.unity.xr.arkit
com.unity.xr.arkit-face-tracking
com.unity.xr.legacyinputhelpers
com.unity.xr.oculus
com.unity.xr.windowsmr
com.unity.xr.magicleap
com.unity.xr.arsubsystems
com.unity.xr.interactionsubsystems
Are these no longer under active development? Why are they in both categories?
Some of them are dependency packages, some are not meant to be directly instantiated in the project, unless you know exactly what you are doing.
What? Why?
The Package Manager already has the ability to add external sources. What is the benefit of ignoring that and fragmenting things further with yet another way to get stuff?
I propose that instead the default Assets/Packages/manifest.json have an optional line:
"com.unity.modules.experimental": "1.0.0"
People who want to use that stuff can add it to the Package Manager and then access it in the unified approach you’re trying to standardise.
I would prefer better wording instead of simply hiding the preview packages. For example, use words like pre-alpha, alpha, beta, release candidate, etc. The word “preview” could mean nearly anything. If Unity added more details, I would know to treat “pre-alpha preview” differently than “release candidate preview”.
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.
That is great news, I didn’t know it was possible at all.
Why not just leave the packages where they already are but label them better? For example, instead of calling all of those packages “preview”, you could use more descriptive words like pre-alpha, alpha, beta, release candidate, etc.
Also, it would help game developers if we knew the status of various packages. This list indicates that Unity will be hiding some DOTS, networking, and XR packages. Some transparency about the actual status of each package would help more than hiding packages. For example, does Unity consider DOTS to be pre-alpha, alpha, beta, release candidate, or something else? This would be very helpful when deciding whether or not to use DOTS in game projects. Simply calling it “preview” does not give game developers enough information.
With VR, Unity 2019.4 has some text saying we should switch to the XR packages because other VR packages (Oculus Desktop and OpenVR) are getting removed in Unity 2020. However, this thread indicates the XR packages are being removed in Unity 2020. That is inconsistent. What is the real status of those packages? Which VR/XR package should be used by game developers in Unity 2019 and 2020? In my own testing with Unity 2019.4, the Oculus Desktop package seemed stable, and the XR packages seemed completely busted.
Yes, but since they’ll now be hidden, it’ll be difficult to discover these packages in the first place if you didn’t know about them before.
A lot of them work perfectly fine and can be pretty useful. I’ve been using editor coroutines for a while, but if they were hidden, and I couldn’t see them in the package list, I’d spend some time working on a sub-par approach, not knowing there’s already a perfectly fine solution at our disposal.
The new input system also worked more or less fine a year before it went out of the ‘preview’ phase.
Will users have to regularly browse Unity’s git repository to discover these packages?
I’m also for better labelling – while still being able to see the full list of experimental packages in Unity somewhere.
Another difference is that we can’t just see and follow the removed packages status and history unless we ADD it to the project.
It’s good to be able to browe packages to see what’s on the horizon and the progress of it all.
EXACTLY.
Honestly, this is just appalling.
Unity… You are going backwards.
You know how racing games usually have that “turn around” warning / notification?
GET ONE.
Because you seriously need it.
If you continue with this terrible decision, you will have essentially slapped everyone using one of the listed packages above in the face.
Not to mention you won’t actually be solving the problem. All you did was just move it far, far away. But it’s still there.
Instead of making people’s lives harder (seriously though… How did you even consider this as a “solution”?), how about you pick three (count 'em Unity, THREE) amazing ideas from this thread – integrate them – and then pat yourself on the back for a job well done, and we all act like this never happened.
Capeesh?
They pick the current idea from another thread, they did go overboard though. Basically they are trying to stabilize the workflow for people who aren’t tinkerer and got suck due to bad signaling. SO they move away the package into a place where the tinkerer would go on their own, BUT tinkerer like the ease of use, so they aren’t please by the new workflow imposed on them, many have pointed they just need a sort of toggle somewhere BUT stay inside the editor.
They probably should focus on that, have a switch tuck in an obscure place, which is easy to toggle once you learn about it, and still come with many signal to tell you are in a special unsafe mode.
For the love of god no!
Sure, remove the packages that are no longer under development, it makes sense we don’t want to start using them, but just move preview packages to another tab or leave it like it is. This just makes it harder to go find preview packages!