Reuse-Release Equivalence Principle

No Change
adopt
First Added:June 25, 2026 Updated: July 2, 2026

Reuse-Release Equivalence Principle. The Reuse-Release Equivalence Principle (REP) says the unit of reuse is the unit of release.

Summary

Garden stance: We adopt Reuse-Release Equivalence Principle for our estate.

When to use: Evaluate on a project when the capability clearly fits the requirement.

When to skip: When a simpler alternative already covers the need.

Details

Component Cohesion Context

REP is one of three classic component cohesion principles (Robert C. Martin). Siblings are Common Closure Principle (CCP) and Common Reuse Principle (CRP). Teams cannot maximize all three at once; pick the pain you are solving.

PrincipleGist
REPRelease components as a unit when reused
CCPGroup classes that change together (Common Closure Principle)
CRPGroup classes reused together (Common Reuse Principle)

Practical Signs

SignalLikely fix
Teams copy source files instead of depending on a packagePublish a versioned artifact (REP)
Shared code changes without semver or release notesAdd release process and version pins
Consumers on different commits of the same folderCut releases; document upgrade path
One repo folder, many implicit “versions”Tag releases; treat the folder as one component

Versioning Requirement

REP is not satisfied by grouping code in a shared folder. Consumers must depend on released, versioned artifacts (semver tags, package registry entries, or equivalent). A release bundles a cohesive unit; consumers choose when to adopt each version.

Common Failure Modes

  • Reuse without versioning (every consumer tracks main)
  • Semver on paper but breaking changes in patch releases
  • One giant release train for unrelated modules (REP without CCP or CRP thought)
  • Release process so heavy that teams bypass it with duplication

Related Garden Items