New Package Lifecycle taking effect in 2021.1

Unity Engine
,
1

Hi everybody,

We want to share a couple of upcoming changes to the package lifecycle with you. Starting in 2021.1 alpha and also now in 2021.1 beta, we are changing the way we publish, show and label packages in the Package Manager. In an effort to provide more clarity around package readiness and expected release date, better quality packages, and as a direct response to feedback from you, we’ve created a more rigorous process for labeling packages, as well as new categorizations for packages.

The following summarizes each phase of this new lifecycle.

1600×575 106 KB

Packages now labeled as “Experimental” and “Pre-release” will no longer be discoverable by default in the Package Manager, however they will still be available to you. Your feedback on these early versions of packages is invaluable to us and is a critical part of the package lifecycle process. We’re building out a dedicated forum and a webpage to keep you up-to-date and communicate all the latest available Experimental and Pre-release packages, and we will share details in our beta communications as well.

Experimental
The Experimental phase contains exploratory and cutting-edge packages. They are not meant and have not been tested for production, and they are not necessarily part of any roadmap. While individuals or teams might offer direct support to users for Experimental packages, they are not maintained by official Unity support channels. Experimental packages can be deprecated without being released.
Given the potential risk associated with using Experimental packages in production projects, they will not be discoverable in the Editor’s Package Manager, however you can find information about ongoing Experimental packages in the forum and through Unity beta communications, where you can also find instructions on how to add them to your test projects and discuss them with the developers.

In 2021.1, Preview packages from previous Editor versions will be considered Experimental packages and as such will no longer be discoverable in the Package Manager window. You can discover and find these packages in the previously mentioned forum.

Pre-release
Pre-release packages are actively being developed and need feedback from early adopters. It is expected that those packages will stabilize and reach the Released phase by the next Unity LTS (long term support) release of the year. Pre-release packages are officially supported by Unity and are part of the roadmap. To discover these packages in the Editor Package Manager, you need to enable this option in the Project Settings. Information about these packages will also be shared in Unity beta communications.

1600×1170 178 KB

1600×978 176 KB

Release Candidate (RC) – only available in Alpha and Beta versions
Pre-release packages that will be classified as Released at the time of the current Unity Tech Stream version will be labelled as RC (Release Candidate). This should help you determine whether to use the package in a production environment when the Tech Stream version comes out.

Released
Released packages are the equivalent of the Verified phase of the previous lifecycle. They constitute the default discovery experience in the Package Manager window, ensuring that all packages discovered in the Package Manager by default are fully validated by Unity and safe to use in production projects.

You can find information about specific Released and Release Candidate packages in the Unity Manual. For information about Experimental and Pre-release packages, please go to the forum.

FAQ

  • What happened to packages that were previously available as Preview?

  • All Preview packages will be classified as Experimental in Unity 2021.1. Teams at Unity will promote these packages to Pre-release state when they are on track to become Released by the next LTS release of Unity and they are heading towards a set of stable APIs.

  • Packages can remain in the Experimental stage for an indefinite amount of time. They are unsupported and might not ever be Released.

  • How can Experimental packages be discovered or tested?

  • You will be able to learn about Experimental packages through beta-related communications and in the forum. These packages are high risk and intended only for testing purposes. They will typically be announced for product feedback or specific testing needs.

  • How will deprecated packages be announced?

  • Information about Experimental packages will be shared in a package’s dedicated forum thread.

  • Released packages that are being deprecated will be announced publicly as part of the general communications.

  • Which Unity versions use which lifecycle?

  • Unity 2018 to Unity 2020: Lifecycle v1 (Preview, Verified phases)

  • Unity 2021 and newer: Lifecycle v2 (Experimental, Pre-release, Released phases)

  • How can newer versions of Released packages be discovered and tested?

  • Newer versions of the packages will be released in the Pre-release stage, which is discoverable if you have enabled this option in Project Settings.

  • Where can I find non-released packages that are now not visible?

  • If the packages don’t get to the Pre-release state, we can’t guarantee their availability or support. We recommend that you visit their forum threads to learn about the status so we can help you find an answer.

Thank you!

– the Unity Team

21 Likes
2

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

3

Because 2020 LTS is a stabilization only release and we don’t want to introduce regressions in that version. But thanks for your suggestion.

4

The list is still work in progress. The goal is to have all actively developed user facing experimental packages to be represented on it.

5

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.

6 Likes
6

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?

10 Likes
7

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.

23 Likes
8

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?

2 Likes
9

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.

1 Like
10

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 Shit” and it is very frustraiting.

10 Likes
11

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

Recently I’ve noticed that GitHub - Unity-Technologies/Graphics: Unity Graphics - Including Scriptable Render Pipeline 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 Expose PointCacheAsset textures by kamyker · Pull Request #2030 · Unity-Technologies/Graphics · GitHub. 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.

20 Likes
12
5 Likes
13

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.

9 Likes
14

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

15

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.

9 Likes
16

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.

1 Like
17

Hi @andybak ,

The majority of the listed threads in that forum is locked for replies exactly for that reason.

You can find the right place to post new threads in for any of the listed topics by looking at the location of these overview threads within the forum.

6961394--819932--2021-03-22_17-38-13.png

18

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! :wink:

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.

19

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.

20

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.

1 Like