The ''granule of deployment'' is a collection of software which is ''deployed'' (released to customers, whether internal or external) as an atomic unit.  (This does ''not'' necessarily mean as a single file).  A GranuleOfDeployment should contain one or more GranuleOfRelease''''''s.  Note that the GranuleOfDeployment may be, and frequently should be, coarser than the GranuleOfRelease.

The GranuleOfDeployment is frequently referred to by any or all of the following names, not all of which are necessarily correct:

* Library
* Shared Library/DLL
* Component
* Archive
* Cabinet
* Application/Applet

Some argue that the GranuleOfDeployment should be ''equal'' to the GranuleOfRelease.  This may be convenient for developers and expert users, but may be a pain for end-users who aren't interested in fine-grained (even at the GranuleOfRelease level) dependency tracking.  RpmHell is a well-known example (in the Linux world) of exposing fine-grained dependencies to the user (coupled with an inadequate packaging tool).  However, when multiple granules of release are aggregated, problems that can arise.

The GranuleOfDeployment should have the following properties:

* The GranuleOfDeployment should be tracked/trackable by the OperatingSystem/VirtualMachine/etc.
* All such granules, except for "application-level" granules which are not subject to dependency by other modules, should be versioned in some fashion.  
* There must be no cyclic dependency between granules of deployment.  Note that it is possible for a cycle to arise between two granules of deployment even though there is no cycle among the constituent granules of release.

GranulesOfDeployment may have the following features (it can be argued that this is a ''should'' requirement where the GranuleOfDeployment contains more than one GranuleOfRelease).

* It should be possible for the runtime to "extract" granules of release from the granule of deployment--shared archives (such as JavaArchive''''''s) have this capability.  (Ordinary DLLs do not).
** Otherwise, a single granule of release might be present in multiple granules of deployment, possibly producing conflicts should both granules of deployment be needed.

----
See GrainOfSalt :-)