Difference between Managed and Unmanaged package in Salesforce

Managed Package vs. Unmanaged Packages

 Managed packages differ from unmanaged packages by having some locked components.

Managed Package:

1.Allowing the managed package to be upgraded later. 

2.Managed packages are typically used by salesforce.com partners to distribute and sell applications to 
customers.

Unmanaged Package:

  

1. Unmanaged packages do not include locked components and cannot be upgraded

2.Unmanaged packages are typically used to distribute open-source projects or application templates to provide developers with the basic building blocks for an application. Once the components are installed from an unmanaged package, the components can be edited in the organization they are installed in.

Package Version

ü 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.

ü  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 cannotbe viewed in an installing organization. The only exceptions are methods declared as global, meaning that the methodsignatures 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. 

ü 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.

Deprecating Apex

ü 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. 

ü After you upload another package version as Managed - Released, new subscribers that install the latest package version cannot see the deprecated elements, while the elements continue to function for existing subscribers and API integrations. A deprecated item, such as a method or a class, can still be referenced internally by the package developer.

ü You cannot use the deprecated annotation in Apex classes or triggers in unmanaged packages

Versioning Apex Code Behavior

ü Package developers can use conditional logic in Apex classes and triggers to exhibit different behavior for different versions.

ü This allows the package developer to continue to support existing behavior in classes and triggers in 
previous package versions while continuing to evolve the code.

ü When subscribers install multiple versions of your package and write code that references Apex classes or triggers in your package, they must select the version they are referencing. 

ü Within the Apex code that is being referenced in your package, you can conditionally execute different code paths based on the version setting of the calling Apex code that is making the reference.

ü The package version setting of the calling code can be determined within the package code by calling the System.requestVersion method. In this way, package developers can determine the request context and specify different behavior for different versions of the package.

ü The following sample uses the System.requestVersion method and instantiates the System.Version
class to define different behaviors in an Apex trigger for different package versions.

trigger oppValidation on Opportunity (before insert, before update) {

for (Opportunity o : Trigger.new){

// Add a new validation to the package

// Applies to versions of the managed package greater than 1.0

if (System.requestVersion().compareTo(new Version(1,0)) > 0) {

if (o.Probability >= 50 && o.Description == null) {

o.addError('All deals over 50% require a description');

}

}

// Validation applies to all versions of the managed package.

if (o.IsWon == true && o.LeadSource == null) {

o.addError('A lead source must be provided for all Closed Won deals');

}

}

}

Apex Code Item that are not Versioned

There are limitations on the changes that you can make to some of these items when they are used in Apex 
code in managed packages.

Package developers can add or remove the following items:

• @future

• @isTest

• with sharing

• without sharing

• transient

Package developers can make limited changes to the following items:

• private—can be changed to global

• public—can be changed to global

• protected—can be changed to global

• abstract—can be changed to virtual but cannot be removed

• final—can be removed but cannot be added

Package developers cannot remove or change the following items:

• global

• virtual

Package developers can add the webService keyword, but once it has been added, it cannot be removed.

Note: You cannot deprecate webService methods or variables in managed package code.