Antony Male

I wonder whether a better way would be to have two methods on the deserializer, one for string responses and one for T responses. That requires a breaking change to...

I think I can change to abstract base classes instead of interfaces without breaking backwards compatibility if I'm careful (I'll add deprecation notices but they won't be mandatory).

There are two things going on here. The first is that RestEase will try and read the response as a string in many cases, and a return type of `Task`...

See #230 - as part of the fix for that, I've introduced `ResponseDeserializer.HandlesStrings`, which lets you write a custom deserializer which customises how strings are handled.

Fair point. I guess the same also applies to `Response` (and also I suppose `Task`, although I'm not sure there's much point in that). I'm somewhat minded to just let...

Ah no, `Response` makes no sense, as it ends up being read as a string anyway.

Sounds reasonable. I can see this working in a number of different ways: 1. Apply all missing migrations before the current migration 2. Un-apply all migrations since the first missing...

Thinking about this, I think it makes sense to add a "skipped migration behaviour" parameter to the commands which migrate up or down, which can take the values "throw an...

Actually, the complication is that I don't currently keep track of the set of migrations which have been applied. The version table forms a history of which migration was applied...

Of course, it would be possible to introduce another table which tracks the currently-applied migrations, but: 1. I have to cope with people who are running Simple.Migrations and don't have...