A package version is a number that identifies the set of
components uploaded in a package. The version number has the format
majorNumber.minorNumber.patchNumber (for example, 2.1.3). The
major and minor numbers increase to a chosen value during every major release. The
patchNumber is generated and updated only for a patch
release.
Unmanaged packages are not upgradeable, so each package
version is simply a set of components for distribution. A package version has more
significance for managed packages. Packages can exhibit different behavior for
different versions. Publishers can use package versions to evolve the
components in their managed packages gracefully by releasing subsequent package
versions without breaking existing customer integrations using the package.
When an existing subscriber
installs a new package version, there is still only one instance of
each component in the package, but the components can emulate older
versions. For example, a subscriber may be using a managed package
that contains an Apex class.
If the publisher decides to deprecate a method in the Apex class and
release a new package version, the subscriber still sees only one
instance of the Apex class after installing the new version. However, this Apex class can
still emulate the previous version for any code that references the
deprecated method in the older version.
Note the following when developing Apex in managed packages:
- The code contained in an Apex class or trigger that
is part of a managed package is automatically obfuscated and cannot be viewed in
an installing organization. The only exceptions are methods declared as global,
meaning that the method signatures can be viewed in an installing
organization.
- Managed packages receive a unique namespace. This
namespace is automatically prepended to your class names, methods, variables, and so
on, which helps prevent duplicate names in the installer’s
organization.
- In a single transaction, you can only reference 10
unique namespaces. For example, suppose you have an object that executes a class in
a managed package when the object is updated. Then that class updates a second
object, which in turn executes a different class in a different package. Even though
the second package wasn’t accessed directly by the first, because it occurs
in the same transaction, it’s included in the number of namespaces being
accessed in a single transaction.
- Package developers can use the deprecated annotation to identify
methods, classes, exceptions, enums, interfaces, and variables that
can no longer be referenced in subsequent releases of the managed
package in which they reside. This is useful when you are refactoring
code in managed packages as the requirements evolve.
- You can write test methods that change the package
version context to a different package version by using the system
method runAs.
- You cannot add a method to a global interface or an abstract method
to a global class after the interface or class has been uploaded in
a Managed - Released package version. If the class in the Managed - Released package is virtual, the method that you can add to it must
also be virtual and must have an implementation.
-
Apex code contained in an unmanaged package that explicitly references
a namespace cannot be uploaded.