REP

Release Reuse Equivalency Principle

“The granule of reuse is the granule of release.” – Robert C. Martin

You cannot reuse a component unless it is managed by a release system (version numbers).

When to use

When organizing your code into libraries or packages for others to use.

Why it matters

Reliability: Users of your component need to know when things change (Semantic Versioning) so they don’t break their apps.
Traceability: You can track which version introduced a bug.

Signs of Violation

“Just copy-paste this folder into your project.”
No changelogs or version numbers.
A library that changes behavior without bumping the version.

Explanation

Problem

If I use your utility library, and you change it silently, my code breaks. I need to be able to “lock” my dependency to version 1.0.0 and only upgrade to 1.1.0 when I am ready.

Solution

Group classes into packages/modules that are released together. Assign a version number to the whole package.

Real world analogy

Car parts. You order a “2023 Model X replacement bumper”. It has a part number and a spec. You don’t just grab “a bumper” from a pile of random plastic.

Pros and Cons

Pros	Cons
Stability for consumers Ordered releases	Overhead of managing versions/packages

Comparison

CCP: CCP tells you what to put in the package; REP tells you how to treat the package (as a release unit).

REP