Package Design Principles
Release/Reuse Equivalency states that everything reused must be released and tracked. This has little to do with writing the code or applying algorithms or data structures but with how to structure your software into smaller components. It requires the maintainer to organize the releases, provide a way to migrate from one version to another and support the older version if the user cannot migrate to a newer version right away.
When applying the principle, you must consider the consequences of supporting the package. The first intuition is to structure your components into multiple tiny modules – after all, when you reuse one of them, you’ll be ready, right? This approach leads to hell with managing the releases of multiple packages. You must notify the user, ensure no changes are breaking, and support the old version for some time.
So, why not go to the opposite side of the spectrum and make your complete application a package? You don’t want your users to drag all the burden of your complete software, including things not meant to be reused, such as logging systems or some authentication. This means that the released package should only contain classes intended to be reused. And this is precisely what the equivalency between reused and released tells about. Be sure that only those things that are supposed to be reused are released in a software package, and be sure that you don’t add items that are not supposed to be reused.
The one thing to consider is what will be reused together in the package you release. Think of it as a Single Responsibility Principle for packages – the package you remove to be reused should contain only those classes needed in the same context. Don’t make some package users use only some part of the functionality.