Ren'Py Schema Changes: fix_rollback() vs Disabling Rollback for Save Compatibility

After a schema change in a Ren'Py project—such as adding a default field to an object stored in the game state—rollback can restore objects that lack the new field. The goal is to prevent rollback from producing an AttributeError while keeping existing saves loadable. Two documented approaches are available: call renpy.fix_rollback() at the schema boundary, or disable rollback for the affected context.

renpy.fix_rollback() prevents rollback from crossing a specific point, which can protect against stale object states. Disabling rollback removes the risk of restoring pre-change objects but changes player-facing behavior. The trade-off is between save compatibility and rollback stability.

The unresolved decision is whether to prioritize saves created before the schema change or the stability of rollback after it. In current Ren'Py releases, rollback behavior and the correct placement of fix_rollback() depend on when the schema change is applied.

Which approach avoids AttributeError without silently breaking rollback for players who rely on it? Does fix_rollback() need to be called before or after the schema change is finalized? How does disabling rollback interact with saves created before the change?