Because version numbers can be handled automatically, descriptions can't. Say, you have app v.20150701 running in production. Today you deployed new version an

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.