vebyast
commented
6 years ago The simple thing would be a "highest migration number" system. Every migration is numbered, and every time the webapp processes a parts list it runs any migrations that are higher-numbered than what the parts list has and brings it up to date.
The problem with this system would be if two people are developing migrations at once; we'd end up with merge conflicts alllll the time as people fight for the next migration number. We may be able to get away with this.
Timestamping won't work because we'd have to set it to the timestamp at time of deployment to be sure we've linearized correctly and nobody accidentally skips a migration. Automatically timestamping new version of the app as CI builds and deploys them might work, but that'd make our deployment process ugh.
The next thing that'd work, stolen from rails, is to make a list of "migrations that've been run on this parts list". Any deployed migrations that don't find themselves in the lists run themselves. Timestamp migrations to make them easier to organize/linearize and it's simple, straightforward, and pretty robust. The problem would be that this would add quite a bit of size to each parts list. I think that we probably won't even get into the hundreds of migrations, though, so this should be reasonable.
So that we can update old parts lists as they're loaded in newer versions of the software. This'd mostly be useful for things like #40 that require broad changes to everyone's lists.