Description
The current spreadsheet migration strategy is based on going through each tab in the spreadsheet, checking the existence of each property and migrating it if necessary, plus migrating all user-friendly fields (names, descriptions etc) regardless of whether changes were made to the metadata or not. This removes the need to know the version of the metadata each tab in the spreadsheet is at prior to migration. One downside of this strategy is that it makes it difficult to add new required columns - this functionality is currently not implemented!
An alternative implementation strategy for migrations could be to first build a full new spreadsheet of the latest schemas (underlying functionality already exists - just requires a function to pull it together), then essentially compare the old and the new spreadsheets tab by tab. Data for properties present in both is copied over, columns present in the new spreadsheet but not the old one are deleted to avoid column overload (unless they are added columns in the migrations list!) and unused tabs are deleted.
The advantage of the latter approach would be that the code duplication between the ingest-client spreadsheet generator and the schema-template-generator app for generating user-friendly headers could be removed. This code duplication has the potential to cause issues if changes are made to one repo and not replicated to the other.