i.e. it might be expected by teams that teammate A writes migration 1 and then B writes 2, and 2 is deployed before 1. In this case they might want the tool to automatically run 1 when it is deployed, even if 2 has been written.
I've had a few ideas about this.
Firstly, there could be a strict mode, on by default, which can be turned off in the rc file. In strict mode, skipped migrations would still be run, and maybe missing migrations might not cause aborts, but not sure about that.
Secondly, there could be a command to run scripts on a per-script basis.
Thirdly, there could be a tool to reorganise scripts, i.e. to change the timestamp on A so that it occurs after B, since even though A was written before B, it was released after A.
Overall though I wonder whether this is an issue. If B does merge their migration in before A, it is surely A's responsibility to reauthor their migration so that it occurs after B.
i.e. it might be expected by teams that teammate A writes migration 1 and then B writes 2, and 2 is deployed before 1. In this case they might want the tool to automatically run 1 when it is deployed, even if 2 has been written.
I've had a few ideas about this.
Firstly, there could be a strict mode, on by default, which can be turned off in the rc file. In strict mode, skipped migrations would still be run, and maybe missing migrations might not cause aborts, but not sure about that.
Secondly, there could be a command to run scripts on a per-script basis.
Thirdly, there could be a tool to reorganise scripts, i.e. to change the timestamp on A so that it occurs after B, since even though A was written before B, it was released after A.
Overall though I wonder whether this is an issue. If B does merge their migration in before A, it is surely A's responsibility to reauthor their migration so that it occurs after B.