Dopo che un sistema ha attraversato numerose migrazioni e si è evoluto abbastanza per una seconda versione, ha senso mantenere le vecchie migrazioni in giro? Voglio dire, le vecchie versioni li useranno per l'aggiornamento a quello nuovo, certo, ma una nuova installazione dovrebbe avere il suo database passare attraverso tutte le modifiche "storiche" prima di arrivare alla forma attuale? Il mio istinto è che una nuova installazione dovrebbe creare il database "così com'è", non passare attraverso ogni errore che è stato fatto nel ciclo di vita del prodotto fino a raggiungere una condizione stabile.
Di recente ho chiesto a una domanda su SO sulla suddivisione di un'applicazione django in più di una. Il problema è che, dopo averlo fatto, non sarò mai in grado di rimuovere la vecchia app, dal momento che le migrazioni passate degli altri si riferiscono ancora ad essa e si interromperanno senza di essa, anche se la versione corrente del mio progetto non usa più. OTOH se avessi "riscritto la storia" in un aggiornamento importante potrei fingere che l'app non sia mai esistita in primo luogo, il che credo avrebbe reso il codice più pulito (comunque le versioni precedenti sarebbero ancora presenti nel controllo di versione).
Lo scenario sopra riportato è solo un esempio, ma sono interessato alle argomentazioni sul caso generale: avere nuove installazioni per creare il database così com'è o passare attraverso ogni migrazione mai effettuata nel ciclo di vita del prodotto?