Versioning and Migration — Easy Chapter Generator

Treat identifiers and serialized listeners as data contracts

Chapter and Objective identifiers are used by Objective Link, public calls, scene handoff, and persistence keys. UnityEvent receiver objects and method names are serialized into scenes and prefabs. Type/field migration attributes preserve older data. A source-compatible code change can still break content if any of these serialized surfaces are changed carelessly.

Safe package upgrade process

1
Read release notes and compatibility requirements before opening the project in a new Unity version.
2
Commit or back up Assets, Packages, and ProjectSettings. Record the current package version.
3
Import into a copy or feature branch and wait for a clean compile.
4
Open representative scenes and prefabs. Run Validation and inspect Objective Link, lifecycle UnityEvents, and identifiers.
5
Run persistence, failure, scene handoff, reset, and custom integration tests.
6
Inspect serialized diffs before accepting the upgrade.

Move from compatibility wrappers deliberately

Obsolete wrappers retained in 1.x protect existing code and UnityEvents while new work uses English methods. Migrate C# call sites first and handle modern return values. Then replace serialized UnityEvent method selections in the Inspector and save their owners. Do not remove migration attributes or wrappers from the package locally.

See Legacy API Migration for representative member mappings.

Plan ID and persistence changes

Change	Risk	Plan
Rename Title	Low; presentation only	Verify UI copy
Rename Chapter/Objective ID	Broken links, calls, handoff, and stored keys	Create explicit data/link migration before release
Delete old content	Orphaned backend keys	Project migration; V1 ClearProgress cannot enumerate removed IDs
Change profile/scope	Existing progress appears absent	Treat as a new namespace or migrate backend records
Replace UnityEvent method	Missing serialized call	Rebind before removing compatibility