1. The Release Reuse Equivalency Principle
"The Granule of reuse is the granule of release"
When developing a reusable components, a class, or a cluster of classes it is important to consider that unless it is managed by a release of some kind, it cannot be fully utilized by the architects. Users will be unwilling to use the class if the author force to upgrade all the code that have been developed around the previous release needed to modify when an upgrade is released for the package. Therefore, one criteria is to package all the classes that are dependent on one another into one package and each package when released should individually support older versions.
2. The Common Closure Principle
"Classes that change together, belong together. "
It is important to note that every large project consists of huge inter-related packages. Each time a package is released, there need to be a number of tests, rebuilds and deployment needed to be performed. To minimize this hiccups, we need to group the packages that are dependent on one another together. This requires a certain amount of precedence as we need to anticipate beforehand what are the changes that needed to be made when one of the class in the package changes. Grouping the dependent packages together will minimize the release and deployment whoes.
3. The Common Reuse Principle
"Classes that aren't reused together should not be grouped together"
A dependency upon a package means a dependency upon everything inside the package. When a new package is released, every class of the package is being verified even if nothing has been used. For the classes that are not being used if clubbed together into one package, any change on their release could also need the other dependent package which even if not using the new update needed to be verified with the new release.
The three principles correspond to the Package Cohesion Principles are mutually exclusive and they cannot be simultaneously be satisfied.