Migration organization

[bobmcwhirter]

The SeaORM migrations should be numerically ordered, but for right now, we can re-number and inject in-between.

But we need to sort out a strategy to "freeze" migrations upon release, else we'll annoy users.

I think as we approach release, we compress the numbering to be consecutive/monotonic, and/or glom them all into a single migration, and then start again with the subsequent set of migrations.

Maybe.

[jcrossley3]

I think we're getting close to the "freeze" point. And I think we could use some practice crafting migrations to account for existing data. So I propose that we strive to never change migration source files at all -- every change to the database schema should come in the form of a brand new migration.

I know we're still feeling our way around the database, but it's not too soon to start creating examples of migrations that actually migrate our data -- not only schema changes but updates to existing things, in both the up and down fns.

I think it's totally fine punting for big changes up to our first official release. For smaller changes, i think it'd be good to develop a corpus of examples future devs can use as guides.

[bobmcwhirter]

Chatting with @jcrossley3 earlier, I think it'd be wise as we approach v1.0 GA (or just prior?) to squash all of our migrations into a single one with the current state of the DDL, and just load that.

Otherwise, our hundreds of migrations from pre-release time end up being a commit history of previously-made mistakes.

After v1, we'd then start stacking migrations again, and before the next release, squash those into their final form.