Concepts

This section explains many of the concepts surrounding the Unity Package Manager functionality:

• Versions
• Manifests
• Registry
• Package Management
• Package states
• Package sources

Versions

Multiple versions of each package are available, marking changes to that package along its life cycle. Every time a developer updates the package, they give it a new version number. A change in package version tells you whether it contains a breaking change (major), a new backward-compatible functionality (minor), or bug fixes only (patch), following Semantic Versioning.

To view the list of versions available for a specific package, see Finding a specific version.

Manifests

There are two types of manifest files:

• Project manifests (manifest.json) These store information that the Package Manager needs to locate and load the right packages, including a list of packages and versions declared as dependencies.
• Package manifests (package.json). These store information about a specific package, and a list of packages and versions that the package requires.

Both files use JSON (JavaScript Object Notation) syntax.

Registry

Unity maintains a central registry of official packages that are available for distribution. A package registry stores package contents and information (metadata) on each package version. By default, all projects use the official Unity package registry, but you can add additional registries to store and distribute private packages or stage packages in development.

Package Management

The Unity Package Manager is a tool that manages the entire package system. Its primary tasks include the following:

• It communicates with the Unity registry and any additional registries you specify.
• It reads your project manifest and fetches package contents and metadata.
• It installs, upgrades, and uninstalls packages, whether they are dependencies of the project or one of the installed packages.
• It enables and disables Unity’s built-in packages.
• It displays information about every version of every package.
• It resolves conflicts when the project and its packages require more than one package version.

The Unity Package Manager installs samples, tools, and assets on a per-project basis, rather than installing them across all projects for a specific machine or device. It uses a global cache to store downloaded package metadata and contents. Once installed, Unity treats package assets just like any other asset in the project, except that these assets are stored inside the package folder and are immutable. You can only permanently change content from Local and Embedded package sources.

Package states and lifecycle

After developing a package to the point where it is ready for Unity users to test it and provide feedback, a package enters the Preview state. Packages in this state usually appear in the Unity Editor with the preview label and often use preview as part of their version.

Unity’s release management only grants a package the verified status after it passes several testing stages and validation procedures, which also include checks for appropriate documentation, changelog, and license files. Packages in this state may appear in the Unity Editor with the 2019.3 verified label and never use preview as part of their version.

If the package developer introduces changing or breaking changes to a package (either by introducing a change that breaks an API or affects its usage), that package returns to the Preview state and the Package Manager does not suggest the new preview package as a possible update for the verified version.

These states indicate where the package is in the development cycle:

The Package Manager window displays a tag that corresponds to some of these states.

Package sources

Sources describe where the package came from:

To edit the package manifest for a package, see Inspecting packages.

The Package Manager window displays a tag that corresponds to some of these sources. For more information, see Tags.