Not by Unity's own definition. Unity says it does not support experimental packages and does not guarantee they will be released or verified as safe to use in production. Packages on the release track (pre-release and released) are supported. Deprecated packages may be nonfunctional or unsafe. These states apply only to packages Unity develops.
The lifecycle in order
Unity's package lifecycle page describes these states, available from editor version 2021.1.
| State | Meaning per Unity | Version pattern |
|---|---|---|
| Experimental | Ready for users to test and give feedback; not supported; no promise of release | Major version 0, or a suffix like -exp.1 |
| Pre-release | On the release track; passed quality testing; fully supported; Unity commits to release it by the end of the current LTS cycle at the latest | A pre suffix on later changes |
| Released | Passed several testing stages and validation, including checks for documentation, changelog and license files | No non-numeric suffix |
| Deprecated | End of life; no longer supported in editors where marked; might be nonfunctional or unsafe | Marked in the Package Manager |
A released package can slide backwards. Unity's table says a breaking API change moves it to experimental (for example 1.2.3 to 2.0.0-exp), a minor change that affects usage moves it to pre-release, and a bug fix keeps it released.
Why this matters for security
An experimental package may change shape or vanish. That is a maintenance risk with a security edge: if a flaw appears, there is no commitment to a supported fix. A deprecated package is worse, because Unity says to avoid it as it might be unsafe.
Also note the scope. Unity's page says these states only apply to packages that Unity develops internally, and tells you to contact third-party package developers about their own processes. A third-party package labelled "1.0.0" has no Unity-backed lifecycle behind it.
A studio rule you can adopt
- Production branches use released packages from Unity's registry by default.
- Pre-release packages need a note in the ticket saying why, and who watches for the final release.
- Experimental packages are allowed in prototypes and R&D branches only. A package that has a zero major version or an exp suffix is a flag in review.
- Deprecated packages are on a removal list with an owner and a date.
- For third-party packages, ask the maintainer how they version, test and fix, and record the answer.
- Review package states at each engine upgrade, because a package can change state between editor versions.
How to spot states quickly
The Package Manager window displays a label for some states. In the manifest, the version string tells you a lot: a version beginning with zero, or with an exp suffix, is experimental by Unity's convention. A scan of Packages/manifest.json and the lock file is a fast way to list candidates. The guide on pinning and the lock file shows what to read.
Safeguard's SBOM and dependency scanning can list the packages declared in your repository, which gives you the inventory to apply this rule against. A free scan is available at gold.safeguard.sh/scan.
Quick check
How do I tell an experimental Unity package from its version?
Unity's documentation says experimental packages use 0 as the major version or an exp suffix on the patch part, such as 1.2.3-exp.1.
Does the lifecycle apply to packages from other publishers?
No. Unity's page limits these states to packages Unity develops and advises asking third-party developers about their processes.
Can a released package become experimental?
Yes, if a major breaking change is made, per Unity's table of version bumps.
Sources
Last reviewed: 19 October 2026.
