'till' argument in downward migrations should stop _before_ undoing that migration

[kael-shipman]

@mbucc, again, very sorry to pepper you with all this stuff. I hope I'm not bothering you too much. (If I am, I can just maintain my own fork of shmig and not worry about trying to stay compatible, but of course, I'd rather there only be one shmig ;).)

This time I've got a somewhat more philosophical issue. When I run shmig up till=some-migration, I expect some-migration to have been applied. Similarly, when I run shmig down till=some-migration, I still expect some-migration to be applied.

Think of it this way: Assuming 123456789-some_migration.sql is the most recent migration, the following calls should produce no state changes at all.

shmig up till=123456789
shmig down till=123456789
shmig up till=123456789
shmig down till=123456789

This makes sense because the till argument should presumably indicate that I want to be on that migration.

Currently, however, the till argument produces the desired effect on upward migrations, but it runs the downward migration through the till argument, not to it.

[mbucc]

On Tue, Jul 17, 2018 at 10:34 PM, Kael Shipman notifications@github.com wrote:

I'd rather there only be one shmig ;)

+1.

This is all good stuff, I'll get to it, just not as fast as you do. :)

[mbucc]

Actually, the current behavior is what I would have guessed. Until to me means up to but not including. The descending case is confusing, I agree, but it was my first guess based on things like (i = 0; i<10;i++) (open on lower end, closed on top) and SQL date range where clauses (again, open on lower end, and closed on the top).

I think the commands could be named better but I think the behavior is OK.

It's also a backward incompatible change, so I need a stronger rationale to justify potentially breaking other people's working scripts. (Assuming someone other than you and I are using this in production ... :)

Since this