The UserDefaultsUpdater class contains many old upgrade methods that require registration domain defaults as input. These upgrade methods possibly no longer work.
Two ways to clean up the mess:
Rewrite the old upgrade methods to work with constant data defined in the private scope of the UserDefaultsUpdater class. This requires digging into the version history past of the project to examine how the registration domain defaults looked like at the time when each upgrade method was implemented. While this solution is certainly the cleanest, the effort vs. benefit is doubtful. How much effort should be put into preserving a pristine user defaults upgrade path since the project was conceived over a decade ago?
Remove the old upgrade methods. It seems quite reasonable to get rid of upgrade methods that are very old (10 years or more), but the closer to the present the upgrade method was implemented the more valuable it appears. Before choosing this solution, a list should be made of how long ago each upgrade method was implemented, then a re-evaluation should be made whether it would make sense to preserve a few of the newest upgrade methhods.
Regardless of which solution is chosen, in the end there should be no more upgrade methods that require registration domain defaults as input. The implementation of the method upgradeToRegistrationDomainDefaults: can then also be simplified to only support one type of upgrade method selector.
The
UserDefaultsUpdaterclass contains many old upgrade methods that require registration domain defaults as input. These upgrade methods possibly no longer work.Two ways to clean up the mess:
Rewrite the old upgrade methods to work with constant data defined in the private scope of the
UserDefaultsUpdaterclass. This requires digging into the version history past of the project to examine how the registration domain defaults looked like at the time when each upgrade method was implemented. While this solution is certainly the cleanest, the effort vs. benefit is doubtful. How much effort should be put into preserving a pristine user defaults upgrade path since the project was conceived over a decade ago?Remove the old upgrade methods. It seems quite reasonable to get rid of upgrade methods that are very old (10 years or more), but the closer to the present the upgrade method was implemented the more valuable it appears. Before choosing this solution, a list should be made of how long ago each upgrade method was implemented, then a re-evaluation should be made whether it would make sense to preserve a few of the newest upgrade methhods.
Regardless of which solution is chosen, in the end there should be no more upgrade methods that require registration domain defaults as input. The implementation of the method
upgradeToRegistrationDomainDefaults:can then also be simplified to only support one type of upgrade method selector.