Unreleased xcdatamodel versions and lightweight migration

Question

If I have multiple unreleased xcdatamodel versions between release A and release B, will lightweight migration still work once I release to the public if I delete the unreleased versions?

Here's a more discrete example:

xcdatamodel version 1.0  --> Release to public A
xcdatamodel version 1.1  --> unreleased (based on v1.0)
xcdatamodel version 1.2  --> unreleased (based on v1.1)
xcdatamodel version 1.3  --> Release to public B (based on v1.2)

I want to make sure that when I submit release B, users coming from release A will be migrated properly. Or is this a completely terrible way to go about it? I understand that if I didn't care about the data on my testing devices, I would just base xcdatamodel version 1.3 on version 1.0 and put everything new in that version - I just don't want to lose the data on my testing devices that have had versions of the app with v1.1 and v1.2 already on the device.

Thanks!

Answer 1

Assuming that the format used for existing user data can be converted to the current format via automatic lightweight migration, it doesn't matter that you created internal, unreleased versions.

What you need to include in the released app: every version that any user might be using. In your case it looks like people would only have 1.0-formatted stores, so there's no need to include 1.1 or 1.2. If that's not the case-- i.e. if there's a user out there somewhere who might have version 1.1 or 1.2 data-- then you need to include them.

So, as long as the 1.0 --> 1.3 changes work with automatic lightweight migration and that no users have 1.1 or 1.2 format data, you could just delete the intermediate versions.

Answer 2

Lightweight migration will only work with certain types of model changes. The best thing is to test this thoroughly. You can safely do the following:

• Add new optional attributes or relationships to an entity
• Add new required attributes to an entity with a default value
• Change an existing optional attribute to required but with a default value
• Rename an attribute or relationship or entity and specify the old name in the "Renaming ID" field of the core data utilities pane tab.

The Core Data Model Versioning and Data Migration Programming Guide lists more operations, but again you should test all this.