Breaking vs Non-Breaking Changes

Every Business System in the Innopo Modular Systems Framework (IMSF) evolves over time. As systems receive fixes, improvements, and new features, these updates fall into two categories: non-breaking changes and breaking changes. Understanding the difference is essential for safe upgrades and long-term maintainability across Projects.

This page explains how IMSF classifies changes, how they affect Projects, and how they influence versioning using the MAJOR.MINOR.PATCHsystem.

Why This Distinction Matters

When a Project depends on multiple Business Systems, even small changes can have cascading effects; impacting workflows, schema, and UI patterns. Clear categorisation ensures that:

• Projects never break unexpectedly
• Upgrade decisions are informed and intentional
• Partners remain confident in platform stability
• System updates can be adopted incrementally

By defining which changes are safe and which require migration, IMSF creates a predictable and transparent evolution path for every Project.

Non-Breaking Changes

Non-breaking changes are updates that do not alter the expected behaviour or interfaces of a system. They are backwards-compatible, meaning any existing Project using the system can upgrade without modifying its workflow logic or schema.

Examples of non-breaking changes:

• Performance improvements
• Bug fixes or reliability patches
• Small UI adjustments that do not change layout structure
• Additional optional fields or configuration options
• New views or components that do not replace existing ones
• Internal refactoring that does not affect public behaviour

These changes correspond to PATCH or MINOR version increments depending on scale:

• PATCH: fixes and tiny improvements
• MINOR: new features added safely

Non-breaking updates never require workflow adjustments or database migrations unless the Project chooses to use a new optional feature.

Breaking Changes

Breaking changes are modifications that alter behaviour, remove functionality, or restructure parts of a system such that existing Projects may require updates to maintain compatibility.

Breaking changes typically include:

• Changes to required database schema structures
• Renaming, removing, or restructuring Prisma models
• Modifying state machines or workflow steps
• Removing or changing function signatures
• Replacing a UI pattern with a different interaction model
• Removing or renaming existing configuration properties
• Introducing new required fields or behaviour
• Alterations that affect integrations or API contracts

Any change that might break workflow logic or custom integrations is classified as breaking.

Breaking changes always trigger a MAJOR version increment:

• MAJOR: backwards-incompatible changes

These upgrades require careful review, migration steps, and validation in staging before going live.

How IMSF Determines Change Type

When modifying a Business System, the Innopo team evaluates changes using several criteria to determine whether they are breaking or non-breaking.

A change is considered non-breaking if:

• existing workflows continue to function without modification
• schema remains compatible with current data
• existing UI components behave the same way
• no required configuration changes are introduced

A change is considered breaking if:

• existing Projects may fail after updating
• data migrations require manual review
• a feature or API is removed or replaced
• workflow states or transitions change meaningfully

When in doubt, IMSF treats changes as breaking to protect stability.

Practical Examples

Below are examples that demonstrate the difference more clearly.

Example: UI Component Update

• Fixing padding or spacing → non-breaking
• Changing a dropdown to a modal → breaking

Example: Schema Change

• Adding an optional column → non-breaking
• Renaming or removing a column → breaking
• Changing a field type (e.g., string → integer) → breaking

Example: Business Logic Update

• Fixing a calculation error → non-breaking
• Changing how pricing or scoring works → breaking

Example: Workflow Engine Update

• Adding more optional workflow hooks → non-breaking
• Modifying the core state machine → breaking

How the Change Type Affects Versioning

IMSF uses semantic versioning to communicate the nature of change:

• BREAKING → MAJOR
  The system now includes incompatible changes and requires migration.
• NON-BREAKING NEW FEATURE → MINOR
  New capabilities without disrupting existing behaviour.
• FIXES → PATCH
  Bug fixes and incremental improvements.

This ensures Project maintainers always know what to expect when reviewing new releases.

Impact on Partners

Partners are insulated from most technical detail, but the distinction between breaking and non-breaking changes affects:

• how upgrades are scheduled
• whether workflow logic must be updated
• whether training or onboarding is affected
• how long migration work may take

Non-breaking upgrades can often be implemented quickly. Breaking upgrades involve more planning, testing, and coordination.

Summary

The distinction between breaking and non-breaking changes is central to how IMSF evolves systems safely. Non-breaking changes extend functionality without risk, while breaking changes require careful migration and validation. This clear separation ensures stability across all Projects and predictable evolution across Partners.