Use versions to communicate change boundaries
Website releases use semantic version labels for the public overlay. Application modules and adapters may have their own release identifiers because they can change on different schedules.
Keep compatibility rules explicit
When an API payload, webhook event or provider adapter changes, document the accepted old shape, new shape and migration window. Avoid silent interpretation changes.
Prefer additive migrations before destructive cleanup
Introduce compatible schema changes first, deploy code that understands both states, verify production, then remove obsolete structures in a later release.
Know what is actually reversible
Static website files are easy to roll back. Data writes, fulfilled orders and provider-side actions are not. Release plans should distinguish code rollback from business reconciliation.
Use these patterns to structure a Thonem project, then verify the exact routes, providers, secrets, queues and infrastructure of the deployed environment before changing production.