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.

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.