Versioning and ownership

Choose fixed or independent release versions

Fixed versioning releases a group of packages with one version and suits tightly coordinated libraries. Independent versioning publishes only changed packages and suits packages with distinct consumers.

Applications that are never published may use workspace versions internally, but deployments still need an immutable release identifier.

Record user-visible changes near the code

Changesets or equivalent metadata let contributors state which packages changed and whether the release is major, minor, or patch. Automation can assemble changelogs and versions later.

Semantic versioning only helps when package contracts and compatibility expectations are documented.

Make ownership executable

CODEOWNERS can request reviewers, but ownership also needs service catalog metadata, maintainers, support expectations, and a deprecation policy.

Avoid one platform team becoming the required reviewer for every shared package. Push ownership to teams closest to the domain while maintaining repository-wide standards.

Govern dependencies automatically

• Tag projects by domain, layer, and runtime
• Express allowed dependency directions
• Fail pull requests on forbidden edges
• Detect cycles and deep imports
• Track packages without active owners
• Review exceptions with an expiry date

Deprecate before deleting

Mark the replacement, publish migration instructions, identify consumers from the graph, and set a removal window. Codemods can turn a repository-wide API migration into a reviewable mechanical change.

Atomic refactoring is powerful, but independent deployment means old and new behaviour may coexist in production. Preserve runtime compatibility for the actual rollout window.