Creating the Guid -> Alias map is a more robust way to go, this will simply map a legacy GUID to a new Alias. Then we will convert the database column to store a string (alias) instead of a GUID. We will then have to update all APIs that reference the legacy GUID to reverse lookup the alias based on the Guid -> Alias map and obsolete these APIs. We will also need to create new APIs beside the old ones that allow for referencing an alias instead.
We make the Guid -> Alias map a public API so that people can add their own Guid -> Alias maps during app startup so they would be able to write migrated property editors
We would encourage people to create Property Editor aliases with namespaces, like "uComponents.UrlPicker" to avoid any alias conflicts. We should not use the folder name of the manifest because this would make it inconsistent with creating a property editor in c# in which there is no folder name. This alias doesn't really show up anywhere except in the database and wherever we currently reference the GUID in the APIs so the name isn't all that important, it's more important that it is unique.
Though this change will maintain compatibility for people moving from v6 -> v7, the opposite is not true:
You will not be able to rollback to v6 once you've upgraded to v7 with the db column and data change
You will not be able to export package from v7 to work in v6
Comments
Shannon Deminick
05 Sep 2013, 06:13:57
Need to watch out for the PackagingService! And need to upgrade the package format.
Shannon Deminick
11 Sep 2013, 08:29:27
This is all done, just need to test a bit and merge back to main branch.