> Don’t use complex notations like “x.y.z” for the version number, just use a single integer.
I prefer to use two integers: major & minor version, semver style. Minor version gets incremented if old code can still use new DB (e.g. when adding a column). Major gets incremented when the change is not backwards-compatible (e.g. when renaming a column).
When you have to rollback a release not having to downgrade the DB can be a major time saver.
Why not timestamps + description? This way, even if you create migrations on different branches, you don't have version number overlap. Rails does that if I remember correctly.
Because version numbers can be handled automatically, descriptions can't.
Say, you have app v.20150701 running in production. Today you deployed new version and it ran migration script against production DB. Two days later you discovered a critical issue in your new version and are forced to roll back to the old app. Now, your 20150710 app opens the database and notices that it has 20150811-oh-we-did-something-to-the-db.sql migration applied. Can it use the database or should it fail/downgrade the DB? How do you tell if all you have is a timestamp and description?
IMO this is more important than solving branch merges because it helps me when my production system is down and there's pressure to bring it back online ASAP. Merging branches can be done offline in the cozy comfort of my development environment.
PS. Of course, the above scenario might be more or less relevant depending on your development and deployment workflows.
Interesting point, though I've never thought about this situation because I've never worked with software versioning. If I need to rollback, I have to check which migrations are present in the SCM repository in a specific revision that I need to rollback to
I prefer to use two integers: major & minor version, semver style. Minor version gets incremented if old code can still use new DB (e.g. when adding a column). Major gets incremented when the change is not backwards-compatible (e.g. when renaming a column).
When you have to rollback a release not having to downgrade the DB can be a major time saver.