[Glass] Class renames and migrations: practices?

[Johan Brichau via Glass]

Hi all,

I noticed an issue in the way we deal with class renames and instance migrations in our application upgrades. In summary, when we left an ‘old’ class (which was ‘renamed' to a ‘new’ class) in the code base during future upgrades, we could inadvertently trigger a migration of the instances of the 'new’ class back to the ‘old’ class. This is because both the ‘old’ and ‘new’ classes share their classHistory and we load application upgrades with Metacello/Monticello and GsDeployer, which also handles classHistory.

Perhaps there are better ways of handling class renames than what we do? How do other people on the mailinglist handle these?

What we do to handle a class rename in a upgrade of our application code:

1) We keep both the ‘old' class (with the old name) and the ‘new' class (with the new name) in our code base.
2) We load the application code upgrade in our database using Metacello and GsDeployer bulkmigrate.
3) We handle the class rename and migrate all instances as follows:

    SomeOldClass addNewVersion: TheNewClass.
    SomeOldClass migrateInstancesTo: TheNewClass.

4) We remove the old class from the system:

    SomeOldClass removeFromSystem

When we do not do step 4 and we keep SomeOldClass in our code base, subsequent class changes on TheNewClass could trigger the GsDeployer bulk migration to migrate instances of TheNewClass back to SomeOldClass before migrating to the last version of TheNewClass. When we inspect the classHistory of both classes, we notice they are shared and can look like this: SomeOldClass -> TheNewClass -> SomeOldClass -> TheNewClass -> SomeOldClass. It all depends on the changes to SomeOldClass and TheNewClass, package load order, etc… wether or not this would eventually end up in a good state (but most probably not). So, we avoid this issue by explicitly removing the class now in step 4.

So, we only figured this out because we had not done step 4 in migrations in early years and we kept the old classes for ‘legacy’ in our code base. The main question is: is this a good way to deal with class renames in application upgrades?

thanks for any thoughts!
Johan