Toolpad App DOM versioning and migrations

[Janpot]

As we evolve our application format, we sometimes need to make breaking changes. As users upgrade their Toolpad instance their apps shouldn't break.

When we can't add changes to the app definition in a backwards compatible way, we will have to migrate it.

I propose:

• we add a version number to the app dom
• A migration function for each version which takes the dom from previous to current version
• On every read from the db, we immediately compare the dom version with the version of toolpad and run necessary migrations
• The application itself will always use the latest version, we reduce migrations to a single point in Toolpad
• Therefore every write will be using the latest versions, as soon as the dom is saved once, the application is migrated on disk.
• We also migrate snapshots on read
• New snapshots will be written using the latest versions
• Old snapshots are never overwritten, migrate on read. In the future we can prompt users to create a new snapshot. not part of this issue

This provides us a good basis to keep working, we can add UI and scripts for migration workflows as the need arises.

[bytasv]

@Janpot wondering if it makes sense to convert this to RFC? Seems like we might have more than one option how it can be done 🤔

[Janpot]

I've reduced the scope to the minimum requirement to keep us moving forward. None of this is user facing. We can introduce migration scripts and UI as the need arises, for which I propose that we open RFCs when needed.