cross-repo-backporting

To keep sibling SaaS products in sync, cross-repo backporting coordinates fleet-wide change propagation by classifying changes as core versus product-specific, ensuring shared behaviors like authentication and billing stay consistent while product-only features intentionally diverge.

The best way to propagate schema migrations across a multi-repo SaaS fleet is authoring migrations once in a canonical product, then verbatim copying them to siblings with sequential numbering per product, strictly avoiding edits to already shipped migrations.

Backporting changes for shared RLS policies requires a canonical-product-first workflow where you land changes in one canonical repo, diff the touched backbone files across siblings, adapt, and produce one scoped backport PR per sibling repo with verification.

You should intentionally diverge behavior across SaaS products for elements like brand assets, user prompts, copywriting, and product-only tables, whereas core behaviors such as authorization, billing, and streaming pipelines must be synchronized to prevent drift.

Yes, cross-repo backporting requires a canonical-product-first landing where the change burns in on a single canonical repository before diffing, adapting, and propagating one PR per sibling repo to ensure safe multi-repo change propagation.

No, you must never edit shipped schema migrations in sibling products; high-stakes migration safety rules dictate authoring once in the canonical product and copying verbatim to avoid corrupting shared data across the SaaS fleet.