Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

After a system has gone through many migrations, and evolved enough for a second version, does it make sense to keep the old migrations around? I mean, old versions will use them to upgrade to the new one, sure, but should a fresh install have its database go through all the "historical" changes before arriving at the current shape? My gut feeling is that a fresh install should create the database "as it is", not go through every mistake that was made in the product lifecycle until reaching a stable condition.

I've recently asked a question on SO about splitting a django app into multiple ones. Problem is: after I've done that I'll never be able to remove the old app, since the other ones' past migrations still refer to it, and would break without it, even if the current version of my project does not use it anymore. OTOH if I "rewrote the history" in a major update I could pretend that the broken app never existed in the first place, which I believe would make the code cleaner (past revisions would still exist in version control though).

The above scenario is just an example, but I'm interested in arguments about the general case: have fresh installs create the database as it is, or go through every migration ever done in the product lifecycle?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Yes, it's a good idea to clean up migration history. Having numerous migrations is really error prone. So it's good idea to make the current state of your servers into the new initial migration.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.