Many existing migrations scripts offer generation as generally the developer will apply db changes, then get it working how they want it, then create a migration.
This is more complicated, error prone and only covers transitions that are accounted for. Which means, this is also a reduction in functionality compared to what is currently possible.
Also generated migrations are less likely to break.
What would be an example of database updater "breaking"?
As for timestamp.php, how will this not work for more than 1 migration?
Which of the following files contain changes for pruning users?
Again, this is what existing migrations libs do
I am yet to see a migration library that uses timestamp only for identifying migrations. I would definitely be interested in seeing such a beast.
The only time I can imagine it would be acceptable is for write-only code, which phpbb is generally not.
and the only problem would be is when two migrations are made at the exact same second which is very unlikely but easy to resolve.
It's more likely than you think, because people copy paste. As a matter of fact, I would not use a timestamp, especially one with a second resolution, to uniquely identify anything.
They can be called their timestamps. I'm saying that instead of
timestamp_name.php and the class being
timestamp_name it should just be
timestamp.php and class being
Last time I checked 1354441865 was not a legal class name in php.