Official New Package Lifecycle taking effect in 2021.1

Hi
Thanks for this new flow, way better then previous.

Q:
Why not start new workflow for new Unity LTS (2020) that will be released in almost half a year (5 Months)?

Q:
Packages in dedicated forum is good but when there will be available all Experimental packages that unity have?
i.e. now there zero packages from ECS ecosystem

 

I like this, I think it better aligns with the goal of giving most users a better idea of what should be stable.

But will it rein in the Unity marketing machine that has been driving users towards unstable packages for ages? For instance, a large marketing push started for LWRP and HDRP before they were even close to being ready (Hey, LWRP is production ready! Canceled!), same for DOTS, etc. Being more realistic about what stage things are in, in terms of bugs and stability, won't do much to change the situation if the marketing engine is just driving everyone into the meat grinder.

As a contractor, I'm often surprised to come into projects (of well funded studios, mind you) and discover that they are doing things like "Requiring that everything be built on the Hybrid Renderer v2", simply because they heard it was the latest thing, often without really understanding the tradeoffs involved. So while I think it's great for Unity to talk about what they are working on, and get early versions out there, and hope that continues, having Jochanim give a talk at Unite and show stuff off is very different than putting it on the front page of Unity's blog and twitter as if everything is ready to go.

 

So let me get this straight. You invented packages, so you you can release stuff independently from Unity versions and get smaller engine size and all that jazz.

And now...
- packages are tied to engine release cycle... (???)
- packages aren't discoverable in the manager, so experienced users, who know what they are doing still should visit various places to get info what to look for instead of accepting the warning that there be dragons...
- more and more built-in packages which couldn't be even removed without chain-reaction
- and the engine size went from ~3Gb to ~6.5Gb

So we have the packages, so I can spend another hour to pick them one by one and wait for the recompile every single time.
Are there enough advantages for us, users to still have packages?

 

I VERY heavily believe there should be a way to enable experimental packages in the editor viewer. Put it in the editor settings with a big warning, or even have it as a manual ini file change.

Experimental packages should allow those who wish to experiment (and know the risks) to do so effortlessly, instead of scouring the internet for these packages, which have no single location where they are consistently listed.

Also, a lot of "core" packages are not visible in the editor either!! Imo any package that exists should be somehow visible. I've had so many issues trying to find various packages, even ones that are "ready for production" but are for whatever reason hidden in the listing.

 

What's with e. g. entities. Will it become visible again or is it still "common knowledge" that one must import it as "com.unity.entities" via git?

 

This is actually normal in many other software projects too, as a web dev I have a lot to do with Angular, and I can't use Angular Material 11 with Angular 10, for example.

One of the advantages of the package system is that you only use the packages you need. And for build-in packages, Unity can exclude them from building if they are not used and reduce the build size.

 

The huge problem is that you can not update package that have critical bugs without migrating to the newest version of Unity. Which is ridiculous. Moreover, when updating to the newest version of Unity, packages are sometimes updated automatically, which can introduce more bugs in them.

So imagine you have a critical bug in 2019.4 that Unity resolved as "won't fix" or something, but it is fixed in 2020.1 So you are migrating to 2020.1. It is fantastic, working great and so on. BUT. There is a package named "Superpackage" that was automatically updated to version 8.2 which has a critical bug. But this bug was fixed in version 10.1. But this version is only available in Unity 2020.2. "Superpackage" is working now, but Unity 2020.2 now has a showstopper, which was fixed in 2021.1 beta...

This is how working with Unity feels when using packages tied to Unity versions (like graphics). This usually called "The Wheel of S***" and it is very frustraiting.

 

Old post I've sent ~20 times but no one read it from Unity:

---
Recently I've noticed that https://github.com/Unity-Technologies/Graphics has not only scriptable pipeline packages but also vfx and shader graph. There was a certain feature that was missing in VFX graph that required only one line change https://github.com/Unity-Technologies/Graphics/pull/2030. It was nice to see that my PR got accepted in 4 days.

I have similar changes in other packages lying around as embedded ones in my project. I could try to show them on forums but generally it's a waste of time as there's high chance of no one from Unity seeing them.

This brings up a question: why more (or even all) packages are not on GitHub? If that was the case users would also have motivation to improve them. Not to mention how much time of using messy forums would be saved.
---

Are there any plans to improve communication between users and Unity regarding packages? I can't understand how huge Unreal is fine on github taking PRs but here smaller packages are getting hidden and removed from github.

 

For production ready packages, Unity should also provide bugfix updates for older packages, especially packages in LTS versions. It is only problematic if it is not possible to fix bugs without breaking changes.
Upgrading the major version just because of bug fixes is the wrong way, Unity should invest a little more in package maintenance so that this is not necessary.

 

I'd also like to know Unity's opinion on this

 

This looks way better than before - but the entire packages concept and the way its implemented and managed is still way out of touch with reality in terms of what users actually need and want.

I have not found a single organisation I contract for so far (both big and small) that is not having headaches with packages in some form, and the issue with the "marketing machine" mentioned above is definately the root cause of it all.

I just dont think you can backtrack the fact that a lot of the packages people have issues with still, were being marketed as far back as 2017/2018 for some and its still causing headaches in 2021.

Right now either a package has a bug in your version of unity, or your version of unity has a bug but the packages dont. Getting a little tiring trying to find the right set of options when we should be worrying about developing our projects.

And because absolutely everything is being spun off into a package lately, it sort of feels like they defeat the entire point as to use unity for basic things you need to spend ages getting the right set of 10-20 packages just to do what was once ready to work with at project creation. Usability dumpster fire right there.

 

I think this is an acceptable compromise.

However - one post per package?

There seems to be an almost pathological misuse of the forums here.

Every message board I've used in the past tries to encourage people to post single topic threads and avoid creating "megathreads".

Unity on the other hand seems to do the opposite. Every single one of those discussions will grow to be some 2000 page monstrosity with everyone speaking over one another and all the different questions interleaved.

This is not how you structure a user forum.

You have sub-topics. Just use them. Please.

 

That's rather confusing. I never would have thought of looking there.

On one hand - you've locked the threads which is good.

On the other hand - you've locked the threads! ;-)

Please give the forums a bit of UX love - and that's not neccesarily a design or coding task. A bit of thinking and coordination about how to use them - and a bit of renaming and reorganization - would go a long, way.

 

This seems like it will do nothing but annoy your advanced users who like exploring preview packages, and just make it more tedious for them to discover, test, and offer feedback for these preview packages. As a whole, this seems like just another hoop people have to step through in order to give feedback, which is counterproductive to good software development.

Please allow us to see preview/experimental packages by enabling an option in the editor rather than manually scouring the forums and editing the package repository file.

 

As an Asset Store publisher, all I really want to know is the status of Asset Store adapting to the Package Manager. It would be fantastic to reference dependencies between assets without adding clumsy define symbols.

 

Good with the renaming. The previous one was absolutely terrible.
Bad with hiding experimental packages. Users shouldn't have to jump out of Unity to discover them, or download them. Don't add more mental stress to using Unity! What's so hard about putting a BIG, BAD, RED, warning sign?

And for the love of all that is holy, can you backport this new nomenclature to 2020.3? A lot of people will be using it for a long, long time, and starting new projects in it, and having two different package nomenclatures is again, more confusion and mental stress. Especially since the old one was disastrous... it means you are dooming all your LTS users (supposedly, you are encouraging people to use LTS versions for projects...) to remain on the known bad one.

 

Random forum posts is not a good way to find and access packages. Please, PLEASE reconsider this.

 

Hiding the experimental packages is really complicating ml agents. The huge warning was good enough.

 

I'm here, after several google searches, trying to find the packages I need, wasting time as everyone else.

Edit:

So, for anyone else looking for UI Toolkit, here's how it is right now:

A new project will already have a package called Unity UI. This is not the correct package, but manually add com.unity.ui .... of course... that is the UI toolkit. When it installs, it shows up as "UI Toolkit" in the package manager.

This added level of hidden packages on top of the different UI solutions and inconsistent naming is pretty frustrating, I must admit... and why isn't that package listed under these experimental packages?

 

I am ok with that as long as there is a place for me which list out all the experimental package name, so I don't have to spend hours searching for it.

 

On the forum there is a list of experimental and pre-realese packages

https://forum.unity.com/forums/experimental-pre-release-packages.549/

 

Hi,

I have a grudge about the packages: the documentation included is in markdown (md) making it unusable when you are offline. I can export the .md files into html with Visual Studio Code but the result, although more agreeable to read, is far less practical to navigate (basically the index.md page is useless).

The documentation furnished with the editors is in html; if I click on index.html the page opens in my browser and from there I can navigate to all the pages contained in the documentation folder!

After opening index.html and clicking on "Working in Unity":

​

and then clicking on "Scripting API":

​

No need for an internet connection to browse the editor documentation! Could you do the same for the packages documentation? Please?

​

 

Ah, okay then.

The sooner the better.

 

What about today, do you have an ETA? I have limited access to the internet, I need to be able to browse the packages documentation in off line mode. Thanks.